249726 2022-12-21 10:03:02 -0800 Setting `font-weight` property to 3.14 returns 3 as computed value instead of 3.14 2022-12-22 22:40:56 -0800 1 1 1 Unclassified WebKit CSS WebKit Nightly Build Unspecified Unspecified RESOLVED WONTFIX BrowserCompat P2 Normal --- 175733 1 cdumez cdumez darin karlcow koivisto mmaxfield sam oldest_to_newest 1921123 0 cdumez 2022-12-21 10:03:02 -0800 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 1921124 1 cdumez 2022-12-21 10:05:46 -0800 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. 1921129 2 cdumez 2022-12-21 10:12:28 -0800 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. 1921214 3 cdumez 2022-12-21 14:06:44 -0800 Pull request: https://github.com/WebKit/WebKit/pull/7976 1921392 4 cdumez 2022-12-22 09:23:29 -0800 Actually, our behavior seems to match Blink at least.