The hypothetical box of fixed positioned elements accounted the root scrollbar-gutter on the left twice
Categories
(Core :: Layout: Positioned, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox127 | --- | wontfix |
| firefox128 | --- | wontfix |
| firefox129 | --- | fixed |
People
(Reporter: TYLin, Assigned: TYLin)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files, 1 obsolete file)
This bug was somewhat exposed after bug 728807. With scrollbar-gutter: stable both-edges set on the root element, the hypothetical box position of fixed-pos elements accounts the scrollbar-gutter twice.
I think we need to change this part of the code https://searchfox.org/mozilla-central/rev/46d0387f0b582f00a5722c20d4e6b8693793631b/layout/generic/ReflowInput.cpp#1422-1426. When aCBReflowInput->mFrame is root frame, we need to get the scrollbar size and tweak cbOffset, similar to https://searchfox.org/mozilla-central/rev/46d0387f0b582f00a5722c20d4e6b8693793631b/layout/style/nsComputedDOMStyle.cpp#2009-2019
Comment 1•2 years ago
|
||
Set release status flags based on info from the regressing bug 728807
Updated•2 years ago
|
Comment 2•2 years ago
|
||
See also https://github.com/w3c/csswg-drafts/issues/9904 (only tangentially related tho)
| Assignee | ||
Comment 3•2 years ago
|
||
Remove unused nsPresContext and LayoutFrameType parameters in
InitAbsoluteConstraints() and CalculateHypotheticalPosition() (except for
one usage in NS_ASSERTION).
Improve the documentation for CalculateHypotheticalPosition() and delete the
nearly the same documentation before its definition in ReflowInput.cpp.
In InitAbsoluteConstraints(), we don't need to initialize the offsets local
variable via ComputedLogicalOffsets() since this is the function computing the
offset, and we'll set the four sides of offsets later in the function.
Updated•2 years ago
|
| Assignee | ||
Comment 4•2 years ago
|
||
nsIFrame provides GetScrollTargetFrame() for getting the scroll container
child under a frame. We can implement this for ViewportFrame so that callers
don't need to get the first child and then downcast.
| Assignee | ||
Comment 5•2 years ago
|
||
We have similar adjustments in ViewportFrame::AdjustReflowInputForScrollbars()
and nsComputedDOMStyle::GetUsedAbsoluteOffset.
Comment 6•2 years ago
|
||
Because of the severity and priority rating, I'm marking this fix-optional for current releases, since the team is aware and has rated the issue.
While we are happy to take a patch, and uplift if it's requested, we don't need to keep looking at the bug in weekly regression triage.
Updated•2 years ago
|
Comment 9•2 years ago
|
||
Backed out for causing mochitest failures @ browser_scrollToPoint.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/23289ab8985a932c991cf504742a254dd95436b5
Failure log -> TEST-UNEXPECTED-FAIL | accessible/tests/browser/scroll/browser_scrollToPoint.js
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 11•2 years ago
|
||
Removed Bug 1901652 Part 2 - Implement GetScrollTargetFrame() for ViewportFrame (the original Part 2) that causes the test failures.
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/971fe2822596
https://hg.mozilla.org/mozilla-central/rev/66efe1aeeb01
Comment 15•2 years ago
|
||
The patch landed in nightly and beta is affected.
:TYLin, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox128towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 16•2 years ago
|
||
I'll let this ride the trains because scrollbar-gutter: stable both-edges is rare.
Description
•