CSS round function results in an incorrect value when dividing a sum of numbers by three
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | --- | fixed |
| firefox131 | --- | wontfix |
| firefox132 | --- | wontfix |
| firefox133 | --- | fixed |
People
(Reporter: kizmarh, Assigned: tlouw)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:133.0) Gecko/20100101 Firefox/133.0
Steps to reproduce:
- Open https://codepen.io/kizu/pen/poMRYgg?editors=1100 or the attached HTML
- Look at the first paragraph (simplified example) where the
--resultis calculated asround(down, (7 - 1) / 3, 1). - Look at the more complicated original example, at the elements with a thick hotpink outline.
Actual results:
- In the first paragraph, the result of the calculation is
1. - In the follow-up complex example, the number in the first outlined element is
1and is0in the next one.
Notably, this happens only when there is a calculation involved: (7 - 1) / 2 is buggy, while 6 / 2 is not. Other browsers (Chrome, Safari) handle this correctly.
Expected results:
- In the first paragraph, the result should be
2. - The follow-up example should be the same as the one for the workaround:
0in the first outlined element, and1in the second.
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•1 year ago
|
||
I can repro.
Suspect: bug 1843695, which just enabled abs() and dign() functions on all platforms. So the actual regressor could be bug 1814588
cc: tlouw.
Updated•1 year ago
|
Comment 3•1 year ago
|
||
Set release status flags based on info from the regressing bug 1814588
:tlouw, since you are the author of the regressor, bug 1814588, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 4•1 year ago
|
||
During this calculation: (7 - 1) / 3 is simplified to (2.3333333 - 0.33333334) for some reason, which equals 1.99999996 and rounded down equals 1 and not 2 as expected.
| Assignee | ||
Comment 5•1 year ago
|
||
Product nodes are eagerly resolved during parse time, but sum nodes are
not. This might cause floating point inprecision in sum nodes, which
leads to invalid calculations, e.g. round(down, (7 - 1) / 3, 1) would
end up being round(down, (2.3333333 - 0.33333334), 1), then
round(down, 1.99999996, 1), which equals 1, which is incorrect.
Updated•1 year ago
|
Comment 8•1 year ago
|
||
| bugherder | ||
Updated•1 year ago
|
Comment 11•1 year ago
|
||
Is this something we should consider uplifting to ESR128? Not sure how common this is in the wild.
| Assignee | ||
Comment 12•1 year ago
|
||
Product nodes are eagerly resolved during parse time, but sum nodes are
not. This might cause floating point inprecision in sum nodes, which
leads to invalid calculations, e.g. round(down, (7 - 1) / 3, 1) would
end up being round(down, (2.3333333 - 0.33333334), 1), then
round(down, 1.99999996, 1), which equals 1, which is incorrect.
Original Revision: https://phabricator.services.mozilla.com/D225936
Updated•1 year ago
|
Comment 13•1 year ago
|
||
esr128 Uplift Approval Request
- User impact if declined: Incorrect results of calculations inside CSS calc() function.
- Code covered by automated testing: yes
- Fix verified in Nightly: yes
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: See same in bug.
- Risk associated with taking this patch: None, it has been released for a while now without issues.
- Explanation of risk level: n/a
- String changes made/needed: n/a
- Is Android affected?: yes
Updated•1 year ago
|
Updated•1 year ago
|
Comment 14•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Description
•