1611872 - The scrollbar that displayed by the overflow property is overlaid above the front layer

Status: RESOLVED DUPLICATE of bug 1730503

(DevTools :: Responsive Design Mode, defect, P2)

Description

[lichunbin814]

Attachment: Screenshot at Jan 28 09-43-18.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

Steps to reproduce:

1. switch to RWD design mode
2. open the link https://www.w3schools.com/cssref/pr_pos_overflow.asp
3. scrolling down to 'Browser Support' node
4. click top menu

Actual results:

1. The back layer's scroll bar overlap is overlap on the front layer

Expected results:

1. The front layer should show higher order than the back layer's scroll bar ( like chrome behavior)

Comment 1

[Razvan Caliman [:rcaliman]]

Hi lichunbin814,

We tried but we couldn't reproduce the issue. Are you able to test in the latest Firefox Nightly and let us know if the issue is still happening?

Anything particular about your settings, like "Always Show Scrollbars" option set on the OS?

Comment 2

[Razvan Caliman [:rcaliman]]

We haven't received updated information about how to reproduce this.
I will close this now, but feel free to reopen if there is a list of steps to reproduce consistently.

Comment 3

[Alice0775 White]

I can reproduce the issue on Nightly76.0a1(20200326093308) Wndows10.

Comment 4

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b4948416e874f6499436b15a8f52540c5754f062&tochange=c379b660d5a8c5f9cc39e5d11173b4500077ef1f

Comment 5

[Brad Werth [:bradwerth]]

Matt, we are having trouble reproducing this (on macOS), but it's apparently still happening for the reporter on a Windows 10 machine. The regression window points to Bug 1450360. Can you please test and see if you can reproduce and/or determine if there's a need to update the work done in Bug 1450360?

Comment 6

[Matt Woodrow (:mattwoodrow)]

Miko, any chance you can look at this?

I think the issue is that ScrollFrameHelper::BuildDisplayList is calling MaybeAddTopLayerItems as well as AppendScrollPartsTo.

MaybeAddTopLayerItems is setting the max possible z-index value to try be on top, but AppendScrollParts to scans the list and tries to match the highest value in the list so that it's on top.

We might need something smarter to stop the scrollbars from overlaying the top layer content.

Comment 7

[Tim Spurway [:tspurway]]

hi :gl, could you assign a priority for this one, please?

Comment 8

[Miko Mynttinen]

Botond seems to have worked on this code recently and might know it better.

Comment 9

[Botond Ballo [:botond]]

Hmm. I did change the place where BuildDisplayListForTopLayer() is called, from ViewportFrame::BuildDisplayList() to ScrollFrameHelper::BuildDisplayList(), in bug 1528743. However, that change happened more recently than bug 1450360 (the change identified as regressing this), so I don't think that's the issue.

Comment 10

[Botond Ballo [:botond]]

I can reproduce the issue on Linux, and I can verify that backing out bug 1528743 locally does not fix it.

Comment 11

[Botond Ballo [:botond]]

Attachment: Display list dump

Attached is a display list dump. I believe display item 0x7f14e23aa0c8 is one of the offending horizontal scrollbars. It does indeed have a z-index of 2147483647.

It's unclear to me which are the top-layer items in the display list, but I guess it's one of the earlier items with z=2147483647.

This comment says:

// We want overlay scrollbars to always be on top of the scrolled content,
// but we don't want them to unnecessarily cover overlapping elements from
// outside our scroll frame.

and in the overlay scrollbar case, it computes the z-index via MaxZIndexInList(aLists.PositionedDescendants(), aBuilder).

I guess, since 0x7f14e23aa0c8 is a top-level item in the display list, the preceding items with z=2147483647 will be among aLists.PositionedDescendants()?

I'm not deeply familiar with display list building, so what I'm wondering about is: should subframe scrollbars end up as top-level items in the display list, as opposed to being descendants of some item representing the subframe ("subframe" meaning non-root scrollable frame)?

Conceptually, I feel like what we would like to do, is restrict this maximum to only consider the items inside the scroll frame whose scrollbars we are building, and not enclosing scroll frames (like the root).

Comment 12

[Matt Woodrow (:mattwoodrow)]

(In reply to Botond Ballo [:botond] from comment #11)

I'm not deeply familiar with display list building, so what I'm wondering about is: should subframe scrollbars end up as top-level items in the display list, as opposed to being descendants of some item representing the subframe ("subframe" meaning non-root scrollable frame)?

Unfortunately not. Scrollable subframes aren't stacking contexts (unless other css properties make them one), so content from outside the scrollframe can interleave with content inside. Given that, we generally expect scrollbars (and the rest of the scrolled content) to be in the same display list as their nearest stacking context ancestor (often the top-level).

Conceptually, I feel like what we would like to do, is restrict this maximum to only consider the items inside the scroll frame whose scrollbars we are building, and not enclosing scroll frames (like the root).

I would have expected, at the time we build the scrollbars for subframes, we wouldn't have yet built the top-layer content for the root scroll frame. So it's not obvious why the computation of z-index for subframe scrollbar is coming up with such a high number, nor why they get sorted to be after the top-layer (sorting should be stable, so even with the same z-index, I'd expect top-layer to stay top).

Comment 13

[Botond Ballo [:botond]]

Note: this issue is specific to RDM. On other platforms with overlay scrollbars (e.g. Android), the scrollbars disappear after interacting with them, so by the time you open the menu and it renders, the subframe's horizontal scrollbar will have disappeared.

I attempted to get an rr recording for the issue so we can see where we diverge from expectations, but the combination of RDM + a relatively heavy page with a bunch of script makes it really unwieldy to work with. A minimal testcase demonstrating the issue would help a lot.

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Botond Ballo [:botond] from comment #13)

I attempted to get an rr recording for the issue so we can see where we diverge from expectations, but the combination of RDM + a relatively heavy page with a bunch of script makes it really unwieldy to work with. A minimal testcase demonstrating the issue would help a lot.

I've posted a minimal testcase over on duplicate bug 1731880: https://bugzilla.mozilla.org/attachment.cgi?id=9242361
It's just a scrollable element, which is covered up by some other element. In this case I didn't cover it up entirely, just so you could see a little bit of the scrollbar even in non-RDM mode to get an idea of what's going on; but the bug happens regardless of whether the element is partially or fully covered up.

Would you mind circling back to take a look here, with that testcase?

Comment 16

[Botond Ballo [:botond]]

This issue appears to be fixed in latest nightly.

I will get a fix range.

Comment 17

[Botond Ballo [:botond]]

This was fixed by bug 1730503.