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: | CSS | Assignee: | 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 | ||
Chris Dumez
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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Chris Dumez
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.
Chris Dumez
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.
Chris Dumez
Pull request: https://github.com/WebKit/WebKit/pull/7976
Chris Dumez
Actually, our behavior seems to match Blink at least.