Bug 249726

Summary: Setting `font-weight` property to 3.14 returns 3 as computed value instead of 3.14
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: CSSAssignee: Chris Dumez <cdumez>
Status: RESOLVED WONTFIX    
Severity: Normal CC: darin, karlcow, koivisto, mmaxfield, sam
Priority: P2 Keywords: BrowserCompat
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 175733    

Description Chris Dumez 2022-12-21 10:03:02 PST 
FontSelectionValue is not able to store 3.14. FontSelectionValue::float() returns 3 after storing 3.14.

This causes our Web-facing behavior to differ from Chrome and Firefox for the `font-stretch` CSS property and is causing the following WPT test to fail:
imported/w3c/web-platform-tests/css/css-typed-om/the-stylepropertymap/properties/font-stretch.html
Comment 1 Chris Dumez 2022-12-21 10:05:46 PST 
The code says:
// Since floats have 23 mantissa bits, every value can be represented losslessly.
constexpr operator float() const;

So I expect the loss of precision is not intentional.
Comment 2 Chris Dumez 2022-12-21 10:12:28 PST 
Seems the class uses a int16_t to store the float, after multiplying by fractionalEntropy (which is 4). Then when requesting the float back, it just divides the int16_t by 4. We end up with a precision of 0.25% as a result.

So if I store 3.14%, I get 3% back. But if I store 3.25%, I get 3.25% back.

This loss in precision doesn't match other browsers and is Web-observable since computed values are exposed to the Web.
Comment 3 Chris Dumez 2022-12-21 14:06:44 PST 
Pull request: https://github.com/WebKit/WebKit/pull/7976
Comment 4 Chris Dumez 2022-12-22 09:23:29 PST 
Actually, our behavior seems to match Blink at least.