1803910 - The scrollbar on addons.mozilla.org does not disappear when clicking on a image (with overlay-style scrollbars)

Status: RESOLVED DUPLICATE of bug 1827337

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

Description

[kernp25]

Attachment: firefox_5QNK7ylRXr.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0

Steps to reproduce:

1. Go to https://addons.mozilla.org/firefox/addon/ublock-origin/
2. Click 1 of the images

Actual results:

See attached video.

Expected results:

The scrollbar should disappear after clicking on the image.

Comment 1

[kernp25]

I don't know if the bug has already been reported?

Comment 2

[Daniel Holbert [:dholbert]]

I don't think I've seen this before, no! This bug probably belongs in Layout:Scrolling&Overflow or Web Painting.

I can reproduce in Firefox 107 as well as in latest Nightly, but only if I have "overlay-style scrollbars". (On Linux at least, this shows up as "Always show scrollbars" in about:preferences -- I need to have that setting disabled in order to repro. On other platforms, I think it's an OS-level setting.)

Comment 3

[Daniel Holbert [:dholbert]]

When I reproduce this bug: if I hover my mouse elsewhere for ~2 seconds, the overlay scrollbar disappears and (fortunately) doesn't come back.

But while the scrollbar is still there, I can interact with it (e.g. I can drag it left/right), and it remains there as long as I keep hovering it (i.e. as long as I don't un-hover it for 2 seconds)

Comment 4

[Daniel Holbert [:dholbert]]

emilio, you've worked a lot with our overlay scrollbars -- do you know if this is a known issue?

Comment 5

[Emilio Cobos Álvarez [:emilio]]

It's sort of intentional. The way this carousel happens to work is making a fixed element inside the same scroll container. We generally try to draw the scrollbars on top of everything inside the scroller so that you can still scroll (code). It's just that in this case it looks somewhat awful...

Comment 6

[Gregory Pappas [:gregp]]

Dupe of bug 1756831? (Although bug 1756831 says fixed....so did this regress?)

Comment 7

[kernp25]

(In reply to Gregory Pappas [:gregp] from comment #6)

Dupe of bug 1756831? (Although bug 1756831 says fixed....so did this regress?)

https://bugzilla.mozilla.org/show_bug.cgi?id=1756831#c13 reported the same issue. But it seems this bug has not been fixed?

Comment 8

[kernp25]

Is this bug fixable by Firefox or must the bug fixed by the amo page?

The amo page can fix this bug by itself:

1. User clicks on one of the images in the .ScreenShots-list
2. It sets .ScreenShots-list overflow-x to hidden
3. When the preview closes it sets back the .ScreenShots-list overflow-x to scroll

Comment 9

[kernp25]

If this bug gets not fixed, should someone from amo know about this bug?

Comment 10

[Timothy Nikkel (:tnikkel)]

(In reply to Gregory Pappas [:gregp] from comment #6)

Dupe of bug 1756831? (Although bug 1756831 says fixed....so did this regress?)

Bug 1756831 fixed a problem where one was able to get the scrollbars to show incorrectly in a situation like this, so the problem came up much less frequently. The scrollbars were still drawn on top, it's just that it was harder to get them to show up in that kind of situation. As mentioned in that bug there was a followup I needed to file in order to actually move the draw order of the scrollbars, I didn't just make the change back then because I wanted to do a little investigation to make sure there wasn't a reason we couldn't do that (maybe something with retained display lists needing an invalidation).

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Yeah, Tim replied. We should probably change the painting order here to at least exclude fixed pos / non-real-frame-descendants. Tim are you going to have time to look at this? Otherwise feel free to bounce the ni? back and I can look next week or so.

Comment 12

[Timothy Nikkel (:tnikkel)]

Should be fixed now on nightly, can you confirm?

Comment 13

[kernp25]

Attachment: firefox_ULm8vwOrJu.mp4

Comment 14

[kernp25]

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

Should be fixed now on nightly, can you confirm?

Yes! It works as expected now.

Comment 15

[Botond Ballo [:botond]]

Based on comment 14, can we close this?