Scrollbar differences between light and dark themes

Developer Tools
#1

The DevTools dark theme forces “floating scrollbars” in the style of macOS for all OSes, so that they get out of the way of content. (It has always done this since the dark theme first appeared in bug 836233 around 4 years ago.)

The DevTools light theme does not do anything special with scrollbars. (It is still possible to see floating scrollbars with the light theme on macOS only, since they are a native OS feature there.)

Based on the bugs filed in the intervening time, people appear to react in several ways:

  • They wonder why the themes have different behavior and assume it is a bug
  • Some find the floating scrollbars too hard to grab onto (since we force them on in the dark theme, there’s no way to revert to “regular” scrollbars)

For example of the difference between theme scrollbars on Windows, see this screen capture.

Should we change something here, or is this semi-mystical arrangement okay?

#2

There is some history to this although it should have been done in both light and dark themes (probably a regression).

The original problem we were trying to was that if standard scrollbars overlay content and are always visible they can obscure content in panels with small content areas. As a bonus they also look cool :wink:

The default action of displaying scrollbars over content can cause issues in some circumstances.

In the event bubble popup we actually have scrollbars that overlay one another. Although at least one scrollbar should work neither do because of a platform bug Bug 1331481 - Scrollbar thumb cannot be dragged when CSS filter property set on container. This bug was fixed last week.

Screen Shot 2017-02-04 at 10.17.27.png1024×504 93.6 KB

This wasn’t apparent to me because I use two finger scrolling on my trackpad (I might take time out from jQuery delegated listeners to fix this).

The only thing I can think of doing is wait until an event bubble header is clicked and codemirror appears then get the scrollbar width… if there is one and shrink codemirror by that width… unless the doorhanger itself is not overflowing… except on OSX where scrollbars can be hidden until you scroll :open_mouth:

So this is the problem that floating scrollbars are trying to solve. They still overlay content but are semi-transparent so they don’t obscure content in the same way. If we keep them I am not sure what to do with event bubbles though because of the overlapping vertical scrollbars… I guess we would just have to accept that there is a 20px margin to the right of codemirror blocks in that particular setup.

So my view in a nutshell:

  1. Keeping them:

    • Saves space in content areas, especially for those with low screen resolutions.
    • Has edge cases where the UI has to look a little funky in order to get the scrollbars to work properly.

  2. Removing them:

    • Can waste space in small content areas.
    • Makes design decisions easier in some edge cases.

Personally, I quite like them but if some users find them hard to click they should at least have the option to disable them… on the other hand, having options here would further complicate the issues I mention above.

#3

Thanks, it’s helpful to have this additional context!

I’m not sure what the straightforward fix for things like the event bubble UI would be… Anything with nested scrollable areas that place the scrollbars at the same position is tricky. Maybe a margin is acceptable like you said.

For the scrollbars in general, I also prefer floating scrollbars since they get out of the way, but I might be biased since I am using macOS, where they are the default throughout the OS.

So, I would be in favor of floating scrollbars for light theme too. It would help to hear some additional opinions, either for or against!

#4

Pretty much agree with the pros and cons presented here.

In my opinion the most important is to have the same behavior on both themes.

The good thing about using floating scrollbars everywhere is that the scrollbar behavior will be consistent on every OS. If you develop with OSX, “regular” scrollbars often come as an afterthought, which can be an issue.

The downside is that they are not consistent with the OS scrollbars, so they might be confusing for users. Another potential downside could be the maintenance cost, not sure how bad it is with the current implementation?

I think overall I’d also prefer having floating scrollbars everywhere.

#5

About the event bubble:

The double scrollbar situation started to appear frequently after we switched to the HTML Tooltip, which reduced the height available for the popup. Before that it was really rare to get a scrollbar on the event list. There would usually only be one scrollbar in the code preview.

By design we always try to avoid UIs that can lead to double scrollbars. Floating scrollbars or not, this kind of UIs are hard to use.

At the time we said we should get rid of the code preview and just display the list of events but we didn’t implement it. (https://bugzilla.mozilla.org/show_bug.cgi?id=1278181)

#6

So, I would be in favor of floating scrollbars for light theme too. It would help to hear some additional opinions, either for or against!

For real development, I use the light theme primarily because it doesn’t have floating scrollbars. I’m one of the people that find them difficult to use – they are a bit too small, and their minimum size is much smaller than the minimum size for the native scrollbars.

For example, opening the debugger on this discourse page in the dark theme – here I find the grabbable part much too small, and almost invisible as well:

… whereas the light theme:

That said I don’t actually care how the thing is implemented; I just dislike the current ergonomics.

#7

I guess another bias I have is that I am using a trackpad as my main input device, and on macOS, this means I can use a two finger gesture to scroll anywhere in the scrollable area (so it’s quite rare for me to attempt clicking the scrollbar directly).

Tom, do you have a different setup?

Maybe the “ideal” is something closer to the actual behavior of native macOS scrollbars:

  • If you scroll by gesture or keyboard, a floating scrollbar is shown
  • If you actually approach the scrollbar with the pointer, it becomes slightly wider and easier to grab

Not sure how hard this ideal is to actually implement…

#8

Yeah, I don’t like trackpads generally and so for “real” development I have a mouse. It has a wheel, but for whatever reason (I’m not actually aware of it) I use it in some situations but not others. So, for instance, there was a time recently when the scrollbar wasn’t working at all, and I noticed this because I kept trying to use it and being foiled.

After reading what I’ve written I am not totally sure I would listen to me.

#9

You mean to tell me that you can actually use your scrollbars? because i try to on FF and it just either goes to the top or to the bottom…FAST. ugh i hate that

#10

I am a Dark Theme user. I very much like the floating scrollbars because they take up less space. I use the mouse wheel for short scrolling, and grab the bar for faster scrolling.

TBH I never noticed there are different versions between light and dark. So unless you can reduce code and save work in the future by refactoring, then I’d say: Leave, because there are more pressing issues.

I think the main complains with the floating bars were because of https://bugzilla.mozilla.org/show_bug.cgi?id=1265807 (which has about 8(!) reported duplicates). This was really a big pain: One could not grab the floating bar with the mouse for faster scrolling. Now this is gone: great :slight_smile:

#11

I guess this could be easily mitigated by giving the floating bar a min-height. For instance, it should never be less than, say, 15px.

#12

Visual Studio Code also has floating scrollbars (Used it for a year now, but only noticed now). They are more edgy than round and a bit bigger, but the principle is similar: they are transparent. So my preference would be floating scrolls everywhere (saves space), but the UX bugs mentioned above should be resolved.