Wrong scroll height being reported in some cases
Categories
(Core :: Layout: Scrolling and Overflow, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr128 | --- | unaffected |
firefox133 | --- | wontfix |
firefox134 | --- | verified |
firefox135 | --- | verified |
People
(Reporter: matej.mulej, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files, 1 obsolete file)
958 bytes,
text/html
|
Details | |
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
Steps to reproduce:
The scroll height of an element is wrong in some cases.
I've attached a repro file that will fire an alert if the bug is triggered.
Firefox 130 did worked correctly, the bug was introduced in Firefox 131.
Neither Chrome or Safari fire the alert.
Comment 1•9 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Scrolling and Overflow' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Reporter | ||
Comment 2•9 months ago
|
||
The new repro also shows errors in the latest default branch on mozilla-unified (commit 06a65f0d5e9d).
Comment 3•9 months ago
|
||
The severity field is not set for this bug.
:hiro, could you have a look please?
For more information, please visit BugBot documentation.
Updated•8 months ago
|
Comment 4•8 months ago
|
||
:emilio, since you are the author of the regressor, bug 1906475, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Assignee | ||
Comment 5•8 months ago
|
||
contain: layout usually makes our kids not account for scrollable
overflow, but when computing scroll{Width,Height} we need to (as the
inner scrolled frame won't use containment).
Add a test for contain: layout + border / padding + various display
types.
After this patch, we only fail the grid ones, due to bug 1797305.
Other browsers also fail a variety of subtests here.
Updated•8 months ago
|
Assignee | ||
Updated•8 months ago
|
Comment 6•8 months ago
|
||
Set release status flags based on info from the regressing bug 1906475
Comment 10•8 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7947178ec5dd
https://hg.mozilla.org/mozilla-central/rev/df07eacc2512
https://hg.mozilla.org/mozilla-central/rev/71557120f80e
Comment 12•8 months ago
|
||
The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox134
towontfix
.
For more information, please visit BugBot documentation.
Updated•8 months ago
|
Assignee | ||
Comment 13•8 months ago
|
||
Probably worth letting it ride the trains. Changes to these apis are always tricky.
Comment 14•8 months ago
|
||
This change regressed the matrix-react benchmark quite a lot, about 17%. Is that kind of change expected?
This benchmark has a very primitive Element-like interface and it then switches between channels many times.
Assignee | ||
Comment 15•8 months ago
|
||
No, that's pretty unexpected, though of course it depends on what the page is doing with the scroll{Width,Height} value. Do you know where the source of that benchmark is?
Comment 16•8 months ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)
Do you know where the source of that benchmark is?
The original source is here: https://github.com/mozilla-spidermonkey/matrix-react-bench
Building it now I get a Node error though, so maybe this is easier (and matches our CI version better):
- Clone https://github.com/mozilla/perf-automation
cd benchmarks/matrix-react-bench
python3 -m http.server
- Open
http://localhost:8000/matrix_demo.html
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Comment 17•8 months ago
|
||
Ok, diagnostic and test-case in bug 1936156. This is an artifact of the page being completely unstyled fwiw, but that causes the react code to get confused and think stuff is scrollable when it shouldn't. Still, we should fix it because the expectation of client == scrollWidth/Height if there's no overflow is legit.
Comment 18•8 months ago
|
||
That was fast. Thank you!
Comment 19•8 months ago
|
||
Given that this also fixed bug 1935927, we should probably reconsider this for 134.
Updated•8 months ago
|
Assignee | ||
Comment 20•8 months ago
|
||
Comment on attachment 9441639 [details]
Bug 1931490 - Fix scroll{Width,Height} of overflow: visible frames with contain: layout. r=#layout
Beta/Release Uplift Approval Request
- User impact if declined/Reason for urgency: Fixes regression from padding work.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Comment 0
- List of other uplifts needed: see regression, will send a request for that too
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Relatively specific codepath
- String changes made/needed: none
- Is Android affected?: Yes
Assignee | ||
Updated•8 months ago
|
Updated•8 months ago
|
Comment 21•8 months ago
|
||
I have reproduced this issue with the test case from comment 2, on an affected Nightly 135.0a1 (2024-11-15) running Win 11.
The issue is verified as fixed on latest Nightly 135.0a1 under macOS 14, Win 11 and Ubuntu 24.04.
Comment 22•8 months ago
|
||
Comment on attachment 9441639 [details]
Bug 1931490 - Fix scroll{Width,Height} of overflow: visible frames with contain: layout. r=#layout
Approved for 134RC, thanks.
Comment 23•8 months ago
|
||
uplift |
Updated•8 months ago
|
Comment 24•8 months ago
|
||
This is also verified as fixed on 134 RC (treeherder build) using Win 11, macOS 14 and Ubuntu 24.04.
Description
•