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•1 year ago
|
||
Set release status flags based on info from the regressing bug 728807
Updated•1 year ago
|
Comment 2•1 year ago
|
||
See also https://github.com/w3c/csswg-drafts/issues/9904 (only tangentially related tho)
| Assignee | ||
Comment 3•1 year 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•1 year ago
|
| Assignee | ||
Comment 4•1 year 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•1 year ago
|
||
We have similar adjustments in ViewportFrame::AdjustReflowInputForScrollbars()
and nsComputedDOMStyle::GetUsedAbsoluteOffset.
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•1 year ago
|
Comment 9•1 year 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•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 11•1 year ago
|
||
Removed Bug 1901652 Part 2 - Implement GetScrollTargetFrame() for ViewportFrame (the original Part 2) that causes the test failures.
Comment 12•1 year ago
|
||
Comment 13•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/971fe2822596
https://hg.mozilla.org/mozilla-central/rev/66efe1aeeb01
Comment 15•1 year 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•1 year ago
|
| Assignee | ||
Comment 16•1 year ago
|
||
I'll let this ride the trains because scrollbar-gutter: stable both-edges is rare.
Description
•