1756831 - Overlay scrollbars are displayed above fixed elements

Status: RESOLVED FIXED

(Core :: Layout: Scrolling and Overflow, defect)

Description

[gterras]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

Have a scrollable element and a position:fixed element inside it.

Actual results:

Overlay scrollbars are displayed above fixed element, allowing actual scroll of the underlying element.

See example https://jsfiddle.net/8vcnjy40/13/

Expected results:

The scrollbar should not be hoverable or actionable.

Maybe introduced by https://bugzilla.mozilla.org/show_bug.cgi?id=1147847

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Not specific to GTK scrollbars, macOS has this too.

Comment 2

[Timothy Nikkel (:tnikkel)]

There is a bunch of code in nsGfxScrollFrame.cpp that sets the z index higher than content of overlay scrollbars that is likely responsible.

Comment 3

[Botond Ballo [:botond]]

Yep, specifically this code.

We've seen some issues before where that code computes a larger z-index than we'd like (by including more items in the maximum than it should). See discussion around bug 1611872 comment 12.

Comment 4

[Timothy Nikkel (:tnikkel)]

Does this cause significant problems for you? Can you expand on how this affects you?

Comment 5

[gterras]

Yes it breaks my app modals since there are scrollbars from underlying elements over it.

In case you wonder having position:fixed here is very important as it is to my knowledge the only way to break out an overflow:hidden element boundaries, giving the ability to display a "full screen" modal from anywhere in the markup (which is priceless when composing complex interfaces).

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Timothy Nikkel (:tnikkel)]

Can you explain what steps you are using to reproduce? When I open your testcase I can't get the scrollbar to appear or interact with it.

Comment 8

[gterras]

A hover where the scrollbar is supposed to be (on the right side of the box) is enough for me to trigger the behavior, what's your OS? I can try to reproduce.

Comment 9

[Timothy Nikkel (:tnikkel)]

Interesting. Thanks. Might be Linux specific. I tested on macOS. I can try on Linux and Windows

Comment 10

[Emilio Cobos Álvarez (:emilio)]

I could repro on macOS too, fwiw. Though it was trickier to get the timing right because macOS only shows scrollbars for active scrollers, not when you have the mouse over the scroller like Windows and Linux do.

Comment 11

[Timothy Nikkel (:tnikkel)]

So to reproduce on macOS you mouse over the scrollbars right after page load?

Comment 12

[Timothy Nikkel (:tnikkel)]

Attachment: abgh.html

This testcase scrolls the scrollable div 1 second after load, which makes the scrollbar visible in all browsers I tested. I created it to see what other browsers do when the scrollbar has been made visible on macOS (where there isn't any other convenient way to make the scrollbar visible).

Comment 13

[u693231]

Attachment: addons.mozilla.org.png

This bug is affecting the gallery view on AMO.

STR:

1. Click an image in the gallery.
2. Hover cursor anywhere.

Expected result: The gallery scrollbar is not visible
Actual result: The scrollbar is visible and can be interacted with

When the position:fixed image is present, hovering the cursor in any part of the viewport will cause the scrollbar to appear, this does not happen when the position:fixed image is removed.

Comment 14

[Timothy Nikkel (:tnikkel)]

And you're on Linux?

Comment 15

[Timothy Nikkel (:tnikkel)]

I have a potential patch here https://hg.mozilla.org/try/rev/e328ca4be098c242a1a2741f8082232471524739
Reading code/bug history to see if there is a reason we haven't been doing that sooner.

Comment 16

[u693231]

(In reply to Timothy Nikkel (:tnikkel) from comment #14)

And you're on Linux?

Yes.

Comment 17

[Timothy Nikkel (:tnikkel)]

Attachment: Bug 1756831. When considering mousemoves over scroll frames to show overlay scrollbars rejects mousemove over content descendants that aren't frame descandants. r?emilio

Comment 18

[Timothy Nikkel (:tnikkel)]

Attachment: Bug 1756831. Add test. r?emilio,hiro

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c745539344fb
When considering mousemoves over scroll frames to show overlay scrollbars rejects mousemove over content descendants that aren't frame descandants. r=emilio
https://hg.mozilla.org/integration/autoland/rev/38e3a0e0fab7
Add test. r=emilio

Comment 20

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/c745539344fb
https://hg.mozilla.org/mozilla-central/rev/38e3a0e0fab7

Comment 21

[Timothy Nikkel (:tnikkel)]

A little bit of an explanatory comment.

Linux and Windows overlay scrollbars are a little bit different from Mac overlay scrollbars. Specifically, in order to get overlay scrollbars to show up on mac you have to do some sort of scrolling activity (or have a new scrollable area created). Whereas on Linux/Windows all you have to do is mouse over the scrollable content or the where the scrollbar would be.

Although there are a few ways to make the overlay scrollbar in the testcase here show up on mac (double clicking, or reloading the page) they are fairly edge case-y. On Linux/Windows all you have to do is mouse over the fixed content. This is a bug because the fixed content is not scrollable by the scroll frame. This bug has been in the code for a long time but only more recently began to show up more because overlay scrollbars are becoming possible/more popular on Linux/Windows. This is the bug that we fixed here.

There is a different but related bug here as well, the one that is fixed by the patch in comment 15. Which is that overlay scrollbars are placed on top of all content descendants of the scrollable element, whether or not they are actually scrolled by that element (eg position absolute elements for which the scrollable element is not an absolute container). Classic scrollbars are low in the z-order, they are put in the same layer as the border/backgrounds, see here

https://searchfox.org/mozilla-central/rev/1659f76981610c1b06437e0a34c0c232b48f4c93/layout/generic/nsGfxScrollFrame.cpp#3390

This is fine because we reserve space for the scrollbars, so none of the content that they scroll can be on top of them. Overlay scrollbars on the other hand do not have space reserved for them, so in order for them to be visible at all they need to be above the content that they scroll. We add them to the display list after we have descended into the scrollframe and built it's display list. We look at that display list for any positioned descendants and if any of them have a non-auto, positive z-index we use the maximum such z-index and also insert into the positioned descendants layer. If there is no such z-index we insert into the content layer. We do this because we try not to place the scrollbars too high in the z-index so they are not over top of content that they do not scroll. However this misses one important thing which is that the items in the positioned descendants list are not all scrolled by the current scroll frame.

See this comment for a nice overview of when we implemented this behaviour https://bugzilla.mozilla.org/show_bug.cgi?id=926292#c15 which also points out that we can never do this perfectly as it creates conflicting requirements. However we can still move them down and meet all requirements in many cases (for example the test case here), so that even if the scrollbars are shown in this testcase they will not be able to be targeted by user input because they are below the fixed content (and will also be drawn that way).

I'll file a followup for that patch and link it here when I do.

Comment 22

[gterras]

Hi thanks for the fix I'm running Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0 and while the bug is fixed for the base case it can still be triggered quite easily (on Linux at least) as long as you don't wait for auto-hide to happen, see https://jsfiddle.net/6fz5b04m/28/ for reproduction. Should I open a new bug for this or provide a description here?

Comment 23

[Timothy Nikkel (:tnikkel)]

That should be covered by the followup I mentioned in comment 21, which I haven't had a chance yet to file. Thanks for reporting that issue.

Comment 24

[Timothy Nikkel (:tnikkel)]

Bug 1827337 is the followup I mentioned.