Bug 249726 - Setting `font-weight` property to 3.14 returns 3 as computed value instead of 3.14
Summary: Setting `font-weight` property to 3.14 returns 3 as computed value instead of...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: BrowserCompat
Depends on:
Blocks: 175733
  Show dependency treegraph
 
Reported: 2022-12-21 10:03 PST by Chris Dumez
Modified: 2022-12-22 22:40 PST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.