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•2 years 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•2 years ago
|
||
It seems like this is impacting the Firefox Screenshot overlay as well
|
|
||
Comment 4•2 years 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•2 years ago
|
||
Yeah, probably the top layer fixed-pos containing block shouldn't be affected by scrollbar-gutter...
|
|
||
Updated•2 years ago
|
|
|
||
Comment 7•2 years 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•2 years 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•2 years ago
•
|
||
Clear the regressionwindow-wanted keyword since setting scrollbar-gutter: stable both-edges never works properly on root element.
|
|
Assignee | |
Comment 10•2 years 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•2 years 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•2 years ago
|
||
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Updated•1 year ago
|
|
|
Assignee | |
Comment 14•1 year 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
•