Highlighted area is shifted to the right when "scrollbar-gutter: both-edges" is used (top-layer fixed-pos cb affected by scrollbar-gutter)
Categories
(Core :: Layout: Positioned, defect, P3)
Tracking
()
People
(Reporter: 6k64x4ma, Assigned: TYLin)
References
Details
Attachments
(7 files)
screenshot.webp
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0
Steps to reproduce:
- Load the attached file.
- Open the Inspector and hover over the node in the HTML tree.
Actual results:
- Higilighted area is shifted to the right.
Expected results:
- Not so.
I can reproduce this on Nightly 2021-12-16.
|
||
Comment 2•6 months ago
|
||
Thanks for the report, I can reproduce easily.
I think that what's happening is that the .moz-custom-content-container element also get reserved space because of the scrollbar-gutter: both-edges set on the <html>.
Emilio, am I correct here?
|
|
||
Comment 3•6 months ago
|
||
It seems like this is impacting the Firefox Screenshot overlay as well
|
|
||
Comment 4•6 months ago
|
||
And maybe ::backdrop ?
Navigate to data:text/html,<meta charset=utf8><style>::backdrop { background: tomato; } html { scrollbar-gutter: stable both-edges; background: gold; } </style><html>hello<dialog id=d>modal</dialog><script>d.showModal()</script>, the backdrop doesn't cover the whole page
|
||
Comment 5•6 months ago
|
||
Yeah, probably the top layer fixed-pos containing block shouldn't be affected by scrollbar-gutter...
|
|
||
Updated•6 months ago
|
|
|
||
Comment 7•5 months ago
|
||
Yeah, so all the way from bug 1715112. Ting-Yu, it seems scrollbar-gutter doesn't play nice with fixed pos. In fact, using scrollbar-gutter: stable both-edges on the root triggers this assert.
Can you take a look?
|
Assignee | |
Comment 8•5 months ago
|
||
Some observation:
I added a blue border to ::backdrop for the testcase in comment 4, and notice the blue left border is missing
data:text/html,<meta charset=utf8><style>::backdrop { background: tomato; border: 5px solid blue} html { scrollbar-gutter: stable both-edges; background: gold; } </style><html>hello<dialog id=d>modal</dialog><script>d.showModal()</script>
By looking at the frame tree, Backdrop frame has x=0 while Canvas has x=720.
Canvas(html)(-1)@7f7b0609f0c8 parent=7f7b0609f198 (x=720, y=0, w=60000, h=41190) [content=7f7b02703040] [cs=7f7b0609c408:-moz-scrolled-canvas] <
...
FixedList@7f7b07dd9d80 <
Backdrop(dialog id=d)(1)@7f7b060a04e0 parent=7f7b0609f020 next=7f7b0609fbd8 (x=0, y=0, w=60000, h=41190) [content=7f7b02709020] [cs=7f7b0609e308:backdrop]
So it seems the scrollbar-gutter on the left hand side breaks the assumption that a root frame (and its top-layer fixed-pos cb) is always at x=0.
|
|
Assignee | |
Comment 9•5 months ago
•
|
||
Clear the regressionwindow-wanted keyword since setting scrollbar-gutter: stable both-edges never works properly on root element.
|
|
Assignee | |
Comment 10•5 months ago
|
||
I can reproduce the devtools highlight shift without scrollbar-gutter, so this bug is older.
- Set pref
layout.scrollbar.side=3[1] to force the root scrollbar on the left, and restart the browser. - Open a page with tall content (e.g. test 2) to make the scrollbar appear.
- Open the Inspector and hover over any node.
|
|
Assignee | |
Comment 12•5 months ago
|
||
I think there are few separate issues here.
(A) For devtools highlight shifts bug: .moz-custom-content-container is abs-pos under nsCanvasFrame. When <html> has scrollbar-gutter: stable both-edges, the canvas frame is not positioned at (0, 0), but at (scrollbar-width, 0) due to the gutter space at the left edge of the viewport. Per discussion with Nicolas on #DevTools channel on matrix, the highligher's position is obtained via getBoxQuads() and the coordinate is relative to root frame, not nsCanvasFrame. That's why the highlighter's position is off.
Out of curiosity, I also test AccessibleCaret, which is also an anonymous content under the .custom-content-container, but it doesn't have this position shift bug because its position has been transformed to be relative to custom-content-container.
(B) For top-layer fixed position elements such as ::backdrop, its containing block is placed relative to (0, 0) of the viewport, but with scrollbar or scrollbar-gutter on the left edge of the viewport, they really should be relative to (scrollbar-width, 0) of the viewport. I'm going to fix it in bug 728807.
(C) For screenshot overlay offset issue: it looks like the overlay is correct while moving mouse to select the region on elements, but once clicking on an element, the overlay is off. The bug occurs on a simple abspos <html> or abspos <body> without scrollbar-gutter. I've filed bug 1876592.
|
|
Assignee | |
Comment 13•5 months ago
|
||
|
||
Updated•5 months ago
|
|
|
||
Updated•5 months ago
|
|
|
||
Updated•16 days ago
|
|
|
Assignee | |
Comment 14•15 days ago
|
||
Quote https://github.com/w3c/csswg-drafts/issues/9904#issuecomment-2161022451,
The CSS Working Group just discussed [css-overflow] Top layer containing block and scrollbar-gutter, and agreed to the following:
RESOLVED: (top layer or fullscreen) elements with 'position: fixed' cover the scrollbars/gutters
Description
•