1835371 - DevTools CodeMirror overlay scrollbars don't reappear when you hover them (unlike overlay scrollbars in other places in Firefox)

Status: NEW

(DevTools :: Source Editor, defect, P3)

Description

[PeteS]

Attachment: Screenshot from 2023-05-26 19-28-45.png

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

Steps to reproduce:

Press F12 to open Devtools.
Select a file in Sources pane whose contents vertically overflow the pane.
Wait until the scrollbars fade from view.
Press and hold the down arrow until the cursor causes the pane to scroll.
Release the down arrow and wait until the scrollbars fade from view.
Hover the mouse over where the vertical scrollbar should be.

Actual results:

The scrollbar is not made visible.

Expected results:

The scrollbar should be made visible.

Comment 1

[PeteS]

Attachment: Screenshot from 2023-05-26 19-31-10.png

Forgot to capture the cursor in the original

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Scrolling and Overflow' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Daniel Holbert [:dholbert]]

I can reproduce. This is a bug in DevTools -- the scrollbar here isn't a "real" scrollbar -- it's an element drawn via JS/HTML, responding to user events.

(The relevant elements are <scrollbar> and <slider>, when inspecting the devtools code viewer using the Browser Toolbox.)

When you scroll, the scrollbar gets an attribute active which makes it show up. Then when you stop interacting, there's some JS that runs which dynamically reduces its style="opacity:..." value to 0, and then the active attribute gets removed, which makes this CSS apply:

pointer-events: none;
opacity: 0;

...which (among other things) prevents it from showing up when you hover it.

The current behavior is arguably kind-of good for some use-cases -- it means you can e.g. use your mouse cursor to select a single character at the extreme right edge of a line of code, without the overlay scrollbar suddenly appearing when you hover that area to begin your selection. If you're not actively scrolling, the scrollbar won't get in your way.

But it is inconsistent with how "real" overlay scrollbars behave in Firefox, so it's definitely a bit confusing.

Comment 4

[Timothy Nikkel (:tnikkel)]

I think this behaviour is linux only (or perhaps linux and windows?), I don't think hovering a non-visible scrollable makes it visible on macos, you have to do some scrolling to make it visible.

Comment 5

[PeteS]

Thanks for investigating this so quickly.

As a user it is definitely preferable to have a scrollbar available for the mouse, upon hover. It is self-defeating for a scrollbar to not be immediately usable by the mouse as it has no other practical interaction method. Once I am forced to move the pane with the cursor i no longer require the scrollbar or it's interaction with the mouse and both become redundant. Yes it is occasionally useful to be able to get at the characters at the edge, but any frustration caused by the sudden display of the scrollbar interfering with character selection is not the result of the scrollbar itself, but rather the choice to temporarily hide it. The frustration is prevented by having the scrollbar always visible. There will always be characters that are outside of the pane viewport, horizontally and vertically - it's why the scrollbar is there in the first place. I also want to keep the cursor in the same place because it's great to be able to type and go right back to where i was after scrolling to check a related bit of code - it's why i use the mouse and scrollbar. On a small screen the slight gain of area from a hidden scrollbar can be helpful, but with high res screens and slimline design of scrollbars on modern platforms this gain is far outweighed by the greater benefit of actually using the scrollbar. If i can't interact with the mouse then it's not a scrollbar, just a fancy graphic animation that occurs when i scroll with the cursor.

I apologise if this seems fatuous, but as there was discussion about the use-cases for a scrollbar i thought it okay to add my thoughts.

Comment 6

[Julian Descottes [:jdescottes]]

We have very little control over the codemirror 5 scrollbars, they always seem to be re-implemented in JavaScript.
I believe codemirror 6 no longer does that, so it might fix this issue when we migrate to it.

Comment 7

[Julian Descottes [:jdescottes]]

Will be hard to make progress on this outside of upgrading to CodeMirror 6, so setting P3/S3 for now.