Use floating scrollbars in light theme

[juliandescottes]

Today we are using floating scrollbars only in the dark theme. They behave quite differently from the regular scrollbars, and since most of the team seems to be using the light theme for development we are sometimes missing bugs (recently https://bugzilla.mozilla.org/show_bug.cgi?id=1415825).

We can either remove floating scrollbars or use them everywhere.

This was already discussed this in https://discourse.mozilla.org/t/scrollbar-differences-between-light-and-dark-themes/13403 . The general consensus was to use floating scrollbars in the light-theme too.

I want to confirm this is still ok and start logging bugs in this direction.

[captainbrosset]

I like the looks of floating scrollbars personally but I'm uncomfortable with forcing them in all themes and on every OS.

I understand that the problem here is consistency between our 2 themes, and that we already force them on all OS in the dark theme. But talking about this makes me realize I've always been a bit concerned with the ergonomics of floating scrollbars:

• not consistent with other scrollbars on windows/linux (the majority of our users are on windows),
• hard to see and grab when small (we don't know how many people use trackpads or mouse wheels).

On Mac, hovering over a floating scrollbar reveals an actual gutter with a bigger scrollbar that you can use if you need and they're just the default OS scrollbars, so the 2 problems above are solved. On Windows, that doesn't happen, so not only are they inconsistent. but they can really be hard to use too.

So, to me at least, the only advantage right now is that they look cool. But if that is at the expense of usability, I would vote against this change, and also vote to drop fake floating scrollbars in the dark theme on windows and linux.

[juliandescottes]

I am also against the floating scrollbars, simply because I feel like it's more code to maintain. I didn't mention it in the summary because of the prior discussion in discourse.

So, to me at least, the only advantage right now is that they look cool.

They have another more tangible added value: they should look the same across all OS. One recurring issue we have with scrollbars, is that most of us develop on OSX and don't think about how our screens will look on other OS. Scrollbars are one of the biggest UI differences IMO.

@pbro : agree with most of your points. A few comments:

On Mac, hovering over a floating scrollbar reveals an actual gutter with a bigger scrollbar that you can use if you need and they're just the default OS scrollbars

I don't think that's the case, the floating scrollbars of the dark theme are also using a custom implementation on OSX.

But if that is at the expense of usability, I would vote against this change, and also vote to drop fake floating scrollbars in the dark theme on windows and linux.

If we do go for floating scrollbars everywhere, they need to be improved, agreed. The height issue was already mentioned on discourse, could be addressed with a min-height. Any other UX/UI issue we should think about?

drop fake floating scrollbars in the dark theme on windows and linux.

As mentioned above, the custom implementation is also used in OSX, so if we drop them we should drop them in OSX too.

[julienw]

To push things further, I think there are differences in how users can scroll:

1. they use the scrollbar (either by touching or with the mouse)
2. they use the 2-finger scrolling (enjoyable) or mousewheel (enjoyable on small distances)
3. they use their touch screen to scroll the page (enjoyable on small distances -- also depends on dynamics)

In cases 2/3 the scrollbar is a distraction and could just be floating and small. Having the scrollbar usable is important for case 1 mostly.

I just tried on Linux: the most painful thing with the floating scrollbar is that when the pointer is at the rightmost pixel, the scrollbar isn't selected. This is what makes it very painful to me because screen borders have a special property: you can just throw the mouse against the border and it will stop there. (not true in some cases, like not-fullscreen windows, or 2 screen-setup). So I think at the very least the scrollbar should be selelected in that case.

[juliandescottes]

I just tried on Linux: the most painful thing with the floating scrollbar is that when the pointer is at the rightmost pixel, the scrollbar isn't selected.

I agree the drag area of the floating scrollbars feels too narrow as well. If we keep them, it should also be increased.

[julienw]

I agree the drag area of the floating scrollbars feel too narrow as well. If we keep them, it should also be increased.

It's not only the narrowness: if the scrollbar extends until the border, then it's as if it's infinitely big on that direction (in fullscreen, one-screen setups).

[captainbrosset]

On Mac, hovering over a floating scrollbar reveals an actual gutter with a bigger scrollbar that you can use if you need and they're just the default OS scrollbars

This is what I get on Mac, in both themes:

I don't know how this is implemented, I just assumed that the grow-on-hover effect was the default macOS thing.

[juliandescottes]

As discussed on slack, the OSX dark theme scroll bar is different depending on your OSX setting General > Show scrollbars

The one from @captainbrosset GIF occurs when you are in the "When scrolling" setting. It looks like we only include our scrollbars CSS when the environment meets certain conditions:

Services.appShell.hiddenDOMWindow.matchMedia("(-moz-overlay-scrollbars)").matches

See theme-switching.js

[jryans]

The one from @captainbrosset GIF occurs when you are in the "When scrolling" setting. It looks like we only include our scrollbars CSS when the environment meets certain conditions

Yes, that's correct. If the OS is using its own floating scrollbars (macOS does so with default settings), then we leave it alone and don't install our own.

[sole]

Question: if we didn't add specific support for these bars, would they appear in macOS?

I am concerned that they might be more frustrating and confusing than anything for users of other operating systems, but equally I don't want to forbid users of macOS with them enabled from using them.

[jryans]

For comparison, here is how some common programs handle this on Windows 10:

• Firefox content area: Fixed scrollbar, always present
• Edge content area: Floating scrollbar, thin when scrolling via wheel, hidden when content not focused
• Edge DevTools script editor: Floating scrollbar, but quite transparent so it's somewhat ignorable
• VS Code editor: Floating scrollbar, hidden when content not focused

This suggests to me that modern Microsoft applications on Windows see floating scrollbars as a good solution. Note that it's quite inconsistent across programs on Windows, where they all appear to do whatever they think is best.

[jryans]

Question: if we didn't add specific support for these bars, would they appear in macOS?

I am concerned that they might be more frustrating and confusing than anything for users of other operating systems, but equally I don't want to forbid users of macOS with them enabled from using them.

With default macOS settings (where floating scrollbars come from the OS), we currently do nothing and use those OS scrollbars. If the OS setting is changed to show a fixed scrollbar, then we currently override that and force it to floating.

So, on macOS (which I believe is the only OS with a user option for scrollbar type), removing our code would mean we respect the user's choice effectively and use scrollbars based on their OS setting.

[jryans]

As a point of clarification, there are two main places where we use floating scrollbars:

• Scrollable areas in the toolbar (editors, etc.)
• Viewport area in Responsive Design Mode

I believe it is important for RDM to always have floating scrollbars no matter what, so that it more accurately represents a mobile device.

[bgrins]

I'd prefer we didn't use floating scrollbars at all because of usability and theme loading complexity. But the last time I tried to remove them I checked on Windows 7 and it looked really bad (I assume the reason they were added in the first place). Would be worth revisiting that and getting some screenshots across platforms with/without the floating scrollbars applied.

So, on macOS (which I believe is the only OS with a user option for scrollbar type), removing our code would mean we respect the user's choice effectively and use scrollbars based on their OS setting.

Regardless of what we decide on other platforms, it seems reasonable to never load them in the toolbox on OSX.

[juliandescottes]

For reference, on OSX, if you:

• set General > Show scrollbars to "Always"
• use the dark theme
• patch devtools to stop using floating scrollbars

You get the following UI:

So even on OSX, native scrollbars can look bad.

[captainbrosset]

Here are screenshots of what devtools (undocked) looks like on Windows 10 in both light and dark theme. I included 2 screenshots in each theme, one of the inspector and one of the storage.

In the light theme, things look really good, consistent with the OS. I agree that, however, the scrollbars aren't looking too nice in the dark theme, but I don't think it's a reason to keep this complex code and harder to use floating scrollbars. Can't we change the color of the scrollbar with magic -moz CSS instead?

[juliandescottes]

Thanks for the feedback! It seems that we can't either just remove floating scrollbars or use them everywhere without additional effort. Our options so far:

1. Use floating scrollbars everywhere

Pros:

• consistent UI and behaviour on all OSes
• takes less space (esp. important in small panels)

Cons:

• poor usability
• more code to maintain

To use floating scrollbars everywhere, we would need to fix all the usability issues (some mentioned in the discussion here).

2. Use native scrollbars everywhere

Pros:

• good usability
• consistent with the UI/UX of the browser
• easier to maintain

Cons:

• look bad on dark theme
• can be inconsistent across OSes, implies more testing on dev side

To use native scrollbars everywhere, we need at least to make them look decent on the dark theme. Quickly tried to use "filter: invert" to get darker versions of our scrollbars. Scrollbars looked nice but could no longer be dragged :( . Hopefully this is not a dead end (if anyone knows about previous failed attempts to do that, please shout!)

Proposal

I propose to start by giving a shot at option 2 and assessing the feasibility of styling native scrollbars. If it turns out to be impossible we can then decide between bad looking native scrollbars in dark theme or working on proper floating scrollbars.

[violasong]

Would love to know if we can style the native scrollbars for dark mode! I agree about the better usability of persistent scrollbars. However, if there's no way to avoid light-colored native scrollbars in dark mode, I would vote against it despite the issues it solves -- it's just way too distracting.

[julienw]

Scrollbars looked nice but could no longer be dragged :(

Do you know if there is a gecko bug about this? If no, can you file it one? Who knows, it might be fixed :)

[jryans]

There is a long standing open bug for allowing general web content to style scrollbars. Surprisingly, a spec recently appeared. Unsure if Gecko plans to implement this anytime soon, though.

It appears there is some precedence for telling native scrollbars to invert, since Gecko does this for content on macOS. (However, that may have been added because that's how Safari behaves.) This type of inversion is applied automatically based on the overall background color of the page, not at the request of any CSS.

If we want more control over native scrollbars, we should think about precisely what changes are desired, so we can talk to each team that works on widgets for that platform about it. For example, do we only want to invert the color, and that's it? Or do we want more control over all the different colors? (Which you then have to maintain over time as platforms change... And you'll need different styles for each OS and version of OS...)

To my knowledge, the options available today are:

1. Install a custom scrollbar appearance (used by current floating scrollbars)
2. Use native scrollbars as they are

If we want to create option 3 (tweaked native scrollbars), then let's carefully define exactly what kind of customization is needed and then file a bug.

[juliandescottes]

Thanks @jryans for the summary and listing our current options! I tried to tweak the scrollbar CSS to invert the colors in dark theme without any luck. It's time to look at our options and move this out of a RFC.

I think there have been strong comments both against using the current floating or native scrollbars, so I discarded these 2 options. Remain:

1. File a bug to style native scrollbars.
2. Fix UI/UX for floating scrollbars.

I feel like the current consensus is more towards option 1 (styling native scrollbars) rather than 2, but since the conversation lasted for a while it would be great if everyone could cast their vote here. Note that we could explore the other option if the one we pick fails.

[juliandescottes]

Personally I support fixing floating scrollbars. The code to maintain is pretty small (floating-scrollbars-dark-theme.css), and using it in all configurations means that bugs will be easy to spot. I like the idea of having a consistent UI across all OS.

[julienw]

Slightly in favor of 1 (this could also help more people including web dev maybe), but 2 is likely more actionable and wouldn't be too bad.

[MikeRatcliffe]

There is one situation where floating scrollbars don't work... imaging a bunch of divs within a div... each of these inner divs contain scrollable text.

The problem here with floating scrollbars is that the scrollbars in the inner divs overlay the scrollbars in the outer div, or vice versa, making it inoperable... in reality they perfectly overlay each other but I have offset them here for illustrative purposes:

[juliandescottes]

A small update on this one.

When reviewed we decided that we should try first solution 1 (customize native scrollbars) and then maybe solution 2.

@bgrins started gathering info about the feasibility of solution 1, and it doesn't look easy to achieve at the moment. Note that solution 2 also seems at risk because we are currently moving out of XBL, which would break our current styling. I'm not clear if we could reapply the styling with the non-XBL approach. Probably something we should track too?

I think we still reached an agreement as to what we want as a team, now the question is whether this is technically feasible or not. I will close this, and open a bug, to start centralizing the solutions and technical issues.

[julienw]

@juliandescottes did you open the bug ? if yes, what's the bug number ? Or is it https://bugzilla.mozilla.org/show_bug.cgi?id=1421389 ?

[juliandescottes]

@julienw not yet! (actually forgot about it :/)

Thanks for the reminder, will get to it tomorrow.

[bgrins]

Wanted to update on the current status here. We have decided what we want for devtools (as per https://github.com/devtools-html/rfcs/issues/27#issuecomment-353371581) is to use native scrollbars with some minimal level of styling to make them look OK on the dark theme, as opposed to using overlay (aka "floating") scrollbars as we do today.

The issue is that right now we don't support styling native scrollbars, but this is tracked by https://bugzilla.mozilla.org/show_bug.cgi?id=77790 and the editors draft of CSS scrollbars https://drafts.csswg.org/css-scrollbars-1/. That draft is not yet at a place where we can implement it for the web, but we could implement something as chrome-only to support the devtools use case. In particular, we don't need a ton of control - probably two or three rules similar to https://github.com/w3c/csswg-drafts/issues/1960. cc: @tantek and @upsuper - please correct me if I'm getting any of this wrong.

We'll still need to somehow support overlay scrollbars for Responsive Design Mode (where we emulate mobile devices) and geckoview as well. This behavior is not part of the draft spec for styling scrollbars, but will continue to work as long as we are building the scrollbars with Native Anonymous Content (see next paragraph).

There's a second moving part here which is plans to remove XBL (and eventually XUL) from the scrollbar implementation. The XBL portion is being done in https://bugzilla.mozilla.org/show_bug.cgi?id=1431246 (cc: @timdream), and likely wouldn't have an effect one way or another on supporting CSS scrollbars. The XUL portion (where we would stop using NAC to build the scrollbar DOM but instead implementing it in a single layout frame) isn't tracked yet but we are planning to discuss in more detail in the June meetup, if not before then. I assume that change will have an effect on CSS scrollbars - I'm not sure if it will make it easier or harder.

[captainbrosset]

Good news: Xidorn will start working on the native scrollbars styling implementation (among other web compat bugs he is working on).

[upsuper]

FYI, scrollbar-{face,track}-color properties have landed on Nightly. It works on Windows only at the moment. It's behind pref "layout.css.scrollbar-colors.enabled" but is always usable in chrome code.

It would be appreciated if you can try these properties and provide feedback.

[captainbrosset]

Thanks so much @upsuper! Really glad to hear this. I tested it locally (built from up to date m-c on windows). And was able to successfully use those 2 new properties on scrollable elements:

Works great, allows us to reuse our existing CSS variables, so we can keep on using the native scrollbars but provide them in a way that feels consistent with the current theme!

One thing though, I couldn't find how to apply it to the viewport's scrollbars. For instance, the DOM tree in DevTools (aka the markup-view) is in its own iframe, and the entire document scrolls. There isn't any child element that has an overflow:auto/scroll on it. I wasn't able to style those kinds of scrollbars. Any idea how to do that?

[upsuper]

Thanks for checking!

Scrollbars of viewport are definitely something we didn't think about. That's a great feedback. I think the way forward would be to propagate the scrollbar colors on the root element to the viewport. I filed w3c/csswg-drafts#2696 for the spec update, and bug 1463687 for Gecko change.

[upsuper]

FYI, propagating scrollbar style from root element to viewport has also landed, you should be able to style markup-view now. Feedback welcome!

[captainbrosset]

@upsuper works great now! Even better, since those properties are inherited, I can define them in just 1 location and they'll be applied everywhere in the DevTools UI. Thanks!

[captainbrosset]

Filed this bug for the DevTools changes: https://bugzilla.mozilla.org/show_bug.cgi?id=1464785 @upsuper are the 2 new properties going to ship with 62? Or remain on nightly for now?

[upsuper]

I don't currently have plan to ship them in 62. I'm going to finish some other pieces of this feature (like other platform support, scrollcorner / resizer, add some rendering tests, etc.) first. And also I'd like to get some more feedback probably from outside developers.

But the properties would remain usable to chrome code since 62 (there is no plan to unship it from chrome code), and I guess that should be enough for devtools to use?

[juliandescottes]

We now dropped floating scrollbars on Windows. OSX implementation ongoing.

Note that even after DevTools only uses native scrollbars, we still need to be careful about floating scrollbars from a UX perspective, because some OS/configurations will still use them (eg OSX with touchpad).