1471163 - Get rid of fake floating scrollbars on Linux

Status: RESOLVED FIXED

(DevTools :: Framework, enhancement, P3)

Description

[Julian Descottes [:jdescottes]]

+++ This bug was initially created as a clone of Bug #1464785 +++

Stop using fake floating scrollbars on Linux when Bug 1464723 lands.

Comment 1

[Florens Verschelde :fvsch]

Attachment: devtools-linux-scrollbar-color.png

Could we expand this bug to take into account dark GTK scrollbars (when using a dark theme such as Adwaita Dark) used with the DevTools light theme?

This screenshot shows the the problem in the light theme, and a possible solution (see the markup view's scrollbar) using `scrollbar-color`. Using scrollbar-color removes the GTK rendering and uses a fallback rendering instead, as described here:

Rationale for not using trying to customize GTK rendering: https://bugzilla.mozilla.org/show_bug.cgi?id=1464723#c15

Implementation info:
https://bugzilla.mozilla.org/show_bug.cgi?id=1464723#c16
https://bugzilla.mozilla.org/show_bug.cgi?id=1464723#c17

We could use `scrollbar-color` in `common.css` for both dark and light theme, and get our custom color that fit with the theme well, at the cost of losing the native rendering on Linux.

Comment 2

[Julian Descottes [:jdescottes]]

> Could we expand this bug to take into account dark GTK scrollbars (when using a dark 
> theme such as Adwaita Dark) used with the DevTools light theme?

There is no strong pressure to remove the floating scrollbars at the moment, so we an take a bit more time to address the overall issue.

Note that even though we have comment which mentions only "Windows," we actually apply this on both Windows and OSX at the moment (forgot to update the comment when we removed floating scrollbar for OSX :) )

I guess the only open question is whether we force a custom scrollbar-color on light-theme for Windows and OSX as well as for Linux?

Comment 3

[Florens Verschelde :fvsch]

Attachment: devtools-linux-scrollbar-color-test.png

This is the result I'm getting on Linux when setting the scrollbar-color to:

- thumb: --theme-body-color-inactive
- background: --theme-splitter-color

Victoria, does that result look alright to you? To recap the current situation:

1. On Windows and macOS we are currently happy with how system scrollbars look in the DevTools light theme, so we're not touching them. We _are_ overriding their colors in the DevTools dark theme, to avoid jarring contrast.

2. On Linux + DevTools dark theme, we are using "fake" floating scrollbars; we're thinking about removing them in this bug.

3. On Linux + DevTools light theme, we are keeping the system scrollbars, which can give us jarring results due to the many different system UI themes that exist on Linux, especially if the user or distribution picked a dark UI theme (see previous comments).

We are thinking of overriding scrollbar colors on Linux for both themes, to avoid visual conflicts with the various system UI themes. On Linux, using the CSS `scrollbar-color` property will remove the system UI scrollbar design altogether, and use a fallback rectangular design (this screenshot).
That's not ideal, but the Linux scrollbar situation is a bit messy anyway, and e.g. Chrome on Linux or Chrome-based applications (like Slack) use custom scrollbars instead of system ones.

Comment 4

[Xidorn Quan [:xidorn] UTC+11]

It would probably look better if you use scrollbar-width: thin for them.

Comment 5

[Xidorn Quan [:xidorn] UTC+11]

(Why did I added QA Contact? I don't think I touched that...)

Comment 6

[Florens Verschelde :fvsch]

Attachment: Bug 1471163 - Remove devtools floating scrollbars and set scrollbar-color on Linux; r?jdescottes

Remove the floating scrollbar implementation used on Linux now that CSS scrollbar-color
landed for Linux. Also force scrollbar-color for the DevTools light theme on Linux, to
avoid visual conflicts with dark GTK themes.

Comment 7

[Florens Verschelde :fvsch]

Attachment: devtools-linux-scrollbar-width-thin.png

Here's the result with `scrollbar-width: thin`.

Xidorn, do you know what the best way to apply this style would be? `scrollbar-color` is inherited, so we can set it on the root element, but `scrollbar-width` is not and we have to apply it to every scrollable element in DevTools panel. That's a lot of non-root elements. Looks like our two options would be:

1. set it for dozens of selectors
2. or `* {scrollbar-width: thin;}`

Comment 8

[Florens Verschelde :fvsch]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=968537de56e472174d8e41ca95c91e007885ff7f

Comment 9

[Xidorn Quan [:xidorn] UTC+11]

`scrollbar-width` is designed to be non-inherited. If you need everything to have it, probably using universal selector (*) would be better.

Comment 10

[Florens Verschelde :fvsch]

Thanks. :)

I’ll recap the design questions we have:

A) On Linux, are we okay with using the fallback scrollbar design (see attachment 9014710 [details]), instead of using the system UI scrollbars.
Context: Linux flavors come with many different UI themes, and their scrollbar designs can clash with the DevTools UI (e.g. scrollbars can be light gray, dark gray, orange, blue...), which is why we have fake overlay scrollbars right now in the dark theme, and issues like bug 1495693 in the light theme. It’s also not considered possible on Linux to keep the system UI scrollbars and tweak their colors (unlike what we do on Windows and macOS).

B) If we use the fallback scrollbar design, what colors should we use in the light theme?
Using the same theme variables as in the dark theme, this results in:
- thumb = #b1b1b3 (Grey 40)
- background = #e0e0e2 (“Grey 25”, in betweek Grey 20 and Grey 30)

C) If we use the fallback scrollbar design, should we keep the normal width (around 12px wide) or the “thin” width (around 6px wide)?

Comment 11

[Victoria Wang [:victoria]]

Thanks Florens, I'm glad to see this being addressed!

A) Overriding Linux on both dark/light themes sounds like a great solution.

B) The light theme scrollbars with those variables look a bit under-contrasted - I would suggest lightening up the background color. MacOS uses a very shade similar to Gray 10, but it's reinforced with an outline. For Linux, perhaps we could use the slightly darker Grey 20 background, and keep --theme-body-color-inactive for the thumb. I made a quick mockup for this in which it looks fine, but I'd love to get a sign off from you on how it feels since you can actually test it.

C) I'm finding myself wishing for a middle option of 8-9px :D, but I think we could probably can err on the side of a sleeker/more-content-allowing thin toolbar, since with a developer tool, users probably won't get confused about the scrollbar being de-emphasized.

Comment 12

[Victoria Wang [:victoria]]

It occurs to me that, while most devs probably use mouse scrollers to scroll, thicker scrollbars are useful for clicking/dragging on a very lengthy views.

(Source of realization: I just had Slack at a size at which the scrollbar was half-hidden, and I needed to do a bunch of backscrolling, so I enlarged the window to click the scrollbar rather than dealing with a skinny scrollbar)

Comment 13

[Florens Verschelde :fvsch]

Thanks Victoria, I've used Grey 20 for the background on Linux+Light, and it looks nice to me.
Also keeping the default scrollbar width for now.

New try push:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=14ac43b66431f217f4305d4e2a8d0ba278911720

Comment 14

[Florens Verschelde :fvsch]

Try seems green. There's an intermittent in dt7 so I've restarted dt7 a bunch of times with mixed results.
It looks like it's bug 1496572 (which has a fix that was merged today, so not yet picked up in my test).

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5f44f57c4ae7
Remove devtools floating scrollbars and set scrollbar-color on Linux; r=jdescottes

Comment 16

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/5f44f57c4ae7

Comment 17

[Yuri Khan]

So, am I getting it right that Firefox has replaced GTK scrollbars with a custom implementation on GNU/Linux, but retained system scrollbars on Windows and macOS?

Previously, if I found myself dissatisfied with the looks of GTK scrollbars on my desktop, I would choose a different theme and it would apply to all applications. What do I do now if I dislike the looks of the scrollbars in Firefox?

Comment 18

[Julian Descottes [:jdescottes]]

(In reply to Yuri Khan from comment #17)
> So, am I getting it right that Firefox has replaced GTK scrollbars with a
> custom implementation on GNU/Linux, but retained system scrollbars on
> Windows and macOS?
> 
> Previously, if I found myself dissatisfied with the looks of GTK scrollbars
> on my desktop, I would choose a different theme and it would apply to all
> applications. What do I do now if I dislike the looks of the scrollbars in
> Firefox?

Note that this is just about DevTools scrollbars, not Firefox scrollbars. The goal is to have scrollbars matching the light and dark theme of DevTools, but I suppose we could leave a third linux only option to use system scrollbars.

Florens, what do you think?

Comment 19

[Yuri Khan]

Attachment: 20181106-peripheral-spots.png

(In reply to Julian Descottes [:jdescottes][:julian] from comment #18)

> Note that this is just about DevTools scrollbars, not Firefox scrollbars.

I was under the impression that DevTools now use the experimental implementation of ‘scrollbar-color’ and ‘scrollbar-width’. I am concerned that, when these are rolled out, web sites will start using them and take away my agency in choosing a non-distracting but still informative scrollbar appearance.

Specifically, I find myself distracted by any sufficiently large spot of contrasting color in my peripheral vision.

To minimize distraction, I have customized my GTK scrollbar to display a light gray (normal 3D object) thumb in a slightly darker but still light trough. It conveys information primarily through image details, not color contrast.

I have attached a rough mockup of how I currently see this bug’s page in Firefox 64 beta 4, with things out of my view focus blurred. The red arrows indicate thigs I find distracting, and the green arrow points to my vision of an unobtrusive scrollbar thumb.

This is probably an accessibility issue, and one that cannot be solved by raising contrast.

> The goal is to have scrollbars matching the light and dark theme of
> DevTools, but I suppose we could leave a third linux only option to use
> system scrollbars.

GTK themes have the capability to define a light and a dark subtheme, and applications can choose which to use. I would like it very much if the light DevTools theme used the light GTK scrollbar and the dark DevTools theme used the dark GTK scrollbar if available.

If a GTK theme only provides a light (or only dark) subtheme, I’d consider it a theme deficiency that Firefox or any application is not in position to be fixing. Yes, in a dark Firefox with a dark site, I would consider the whole light scrollbar an annoyance. But it would be directed at the theme maintainer (“why don’t you implement a dark subtheme”) and not at Firefox (“why did you override my preferences”). I could probably even fork the theme and add a dark subtheme on my own *and get the benefits on my whole desktop*.

With web content in general, I imagine my ideal solution would be to choose the light or dark GTK scrollbar based on the overall background of the page. Or just always use the one corresponding to the Firefox theme.

Comment 20

[Julian Descottes [:jdescottes]]

(In reply to Yuri Khan from comment #19)
> Created attachment 9022697 [details]
> 20181106-peripheral-spots.png
> 
> (In reply to Julian Descottes [:jdescottes][:julian] from comment #18)
> 
> > Note that this is just about DevTools scrollbars, not Firefox scrollbars.
> 
> I was under the impression that DevTools now use the experimental
> implementation of ‘scrollbar-color’ and ‘scrollbar-width’. I am concerned
> that, when these are rolled out, web sites will start using them and take
> away my agency in choosing a non-distracting but still informative scrollbar
> appearance.

We are using those properties, but this is probably not the right place to discuss whether websites should or should not customize scrollbar appearance once the properties are standardized and implemented. The focus of the patch here was just to use it for DevTools. Allowing to style scrollbars in Linux seems challenging, you can have a look at Bug 1464723. But again let's keep the conversation here around DevTools scrollbars. 

> 
> Specifically, I find myself distracted by any sufficiently large spot of
> contrasting color in my peripheral vision.
> 
> To minimize distraction, I have customized my GTK scrollbar to display a
> light gray (normal 3D object) thumb in a slightly darker but still light
> trough. It conveys information primarily through image details, not color
> contrast.
> 
> I have attached a rough mockup of how I currently see this bug’s page in
> Firefox 64 beta 4, with things out of my view focus blurred. The red arrows
> indicate thigs I find distracting, and the green arrow points to my vision
> of an unobtrusive scrollbar thumb.
> 
> This is probably an accessibility issue, and one that cannot be solved by
> raising contrast.
> 
> > The goal is to have scrollbars matching the light and dark theme of
> > DevTools, but I suppose we could leave a third linux only option to use
> > system scrollbars.
> 
> GTK themes have the capability to define a light and a dark subtheme, and
> applications can choose which to use. I would like it very much if the light
> DevTools theme used the light GTK scrollbar and the dark DevTools theme used
> the dark GTK scrollbar if available.
> 

While we use `scrollbar-color` here, it's true that we only care about having a light and a dark scrollbar. So if there is a way we can reuse the scrollbars from the theme, why not. I will file a separate bug for this.

> If a GTK theme only provides a light (or only dark) subtheme, I’d consider
> it a theme deficiency that Firefox or any application is not in position to
> be fixing. Yes, in a dark Firefox with a dark site, I would consider the
> whole light scrollbar an annoyance. But it would be directed at the theme
> maintainer (“why don’t you implement a dark subtheme”) and not at Firefox
> (“why did you override my preferences”). I could probably even fork the
> theme and add a dark subtheme on my own *and get the benefits on my whole
> desktop*.
> 
> With web content in general, I imagine my ideal solution would be to choose
> the light or dark GTK scrollbar based on the overall background of the page.
> Or just always use the one corresponding to the Firefox theme.

Comment 21

[Asif Youssuff]

Attachment: Screenshot from 2018-11-05 17-29-55.png

I'm a little confused about what prompted this ticket -- at least on the two GTK themes I am currently using - Adwaita and Yaru, the previous scrollbars prior to this ticket looked totally fine, and as far as I am able to test in Firefox stable, did not disappear or "float".

Is dev tools its own product now with its own styling? If you look at the attachment, you can see different scrollbars *in the same window* - that feels jarring and isn't internally consistent. That feels like a bad experience to me. 

What I really don't understand is why the main Firefox window is fine the way it is -- and why the change here was not done there as well -- if this is a good design for dev tools, it ought to be a good design for the main Firefox window, no? 

In any case, in my testing, it seems that while the normal Firefox scrollbar looks more like the native one, the latest GTK3 apps on my OS are actually using "floating" scrollbars, like are being removed here - that is tracked in 1147847.

I respectfully ask that this change be only applied to the "dark" mode, or that it is not released in Linux unless 1504787 is fixed, since this is a regression in internal consistency in Firefox.

Comment 22

[Julian Descottes [:jdescottes]]

(In reply to Asif Youssuff from comment #21)
> Created attachment 9022827 [details]
> Screenshot from 2018-11-05 17-29-55.png
> 
> I'm a little confused about what prompted this ticket -- at least on the two
> GTK themes I am currently using - Adwaita and Yaru, the previous scrollbars
> prior to this ticket looked totally fine, and as far as I am able to test in
> Firefox stable, did not disappear or "float".
> 

Sorry the title was misleading: floating scrollbars were only used in the dark theme. The current solution allows to have consistent scrollbars in both dark and light themes. It is not perfect but it avoids introducing regressions in the dark theme because most of our testing in done with the light theme.

> Is dev tools its own product now with its own styling? If you look at the
> attachment, you can see different scrollbars *in the same window* - that
> feels jarring and isn't internally consistent. That feels like a bad
> experience to me. 
> 
> What I really don't understand is why the main Firefox window is fine the
> way it is -- and why the change here was not done there as well -- if this
> is a good design for dev tools, it ought to be a good design for the main
> Firefox window, no? 
> 

The main Firefox windows doesn't support dark scrollbars, so they don't have the same issue as DevTools.

> In any case, in my testing, it seems that while the normal Firefox scrollbar
> looks more like the native one, the latest GTK3 apps on my OS are actually
> using "floating" scrollbars, like are being removed here - that is tracked
> in 1147847.
> 

The goal was to remove our custom implementation of floating scrollbars, which was buggy and painful to maintain. If the system has native floating scrollbars and we can style them to look good in both light and dark theme (Bug 1504787), then there is no reason we wouldn't use them.

> I respectfully ask that this change be only applied to the "dark" mode, or
> that it is not released in Linux unless 1504787 is fixed, since this is a
> regression in internal consistency in Firefox.

This means going back to inconsistencies between our themes, but maybe that would be a better temporary solution until we can get to Bug 1504787. Will file another bug for that.

Comment 23

[Florens Verschelde :fvsch]

> [Asif] if this is a good design for dev tools, it ought to be a good design for the main Firefox window, no? 

Not necessarily. But scrollbars on Linux are a pain in the arse and different applications or even parts of Firefox try to handle as well as possible. For instance:

- Chrome uses custom scrollbars instead of the GTK ones (I'm also getting different non-GTK scrollbars in Chrome 69 and Chromium 69; one is a floating scrollbar and the other is a Windows-like scrollbar).
- The Firefox sidebar uses a custom scrollbar instead of the GTK one when using the Firefox dark theme.

> [Asif] If you look at the attachment, you can see different scrollbars *in the same window* - that feels jarring and isn't internally consistent. That feels like a bad experience to me.

If you look at a web page with a light background and devtools with a dark background, you have two very different situations that may call for different solutions. Light GTK scrollbars in the DevTools dark theme, and dark GTK scrollbars in the DevTools light theme, are particularly jarring and can create the same kind of accessibility issue that Yuri reported here (regarding attention deficit disorders).

I don't disagree with your point and I'm all for consistency, but I want to stress that this is a hard design problem (you have sections of dark UI and light UI in the same application, and may inherit light-or-dark controls from GTK that look out of place in either of those sections, so that makes 4 different situations to account for), and that this is a hard-enough technical problem too (4 situations, can't be fully fixed in CSS, and I haven't explored JS-driven solutions yet but they don't seem straightforward).

The best solution would probably be what Yuri suggest, i.e. to ask GTK to use a dark or light subtheme and leave the responsibility to provide such subthemes to theme maintainers. Right now we can't do that in CSS, and I'm not sure we can do it in JS efficiently.

One theoretical solution would be to have `scrollbar-color: light|dark` implemented with the GTK subtheme switching behavior. The relevant bug for that is bug 1492040.

If we can manage this in CSS in the future, I would be happy to switch to `scrollbar-color: light|dark` instead of providing precise colors that trigger a non-GTK fallback design.

> [Julian] The main Firefox windows doesn't support dark scrollbars, so they don't have the same issue as DevTools.

I would say there are related issues (but not the exact same issue) in the menus, sidebar, and to some extent for web content (see the lengthy bug 1158076).
It could be interesting to reach out to other Firefox designers and devs who may be battling this issue too.

> [Asif] I respectfully ask that this change be only applied to the "dark" mode, or
> that it is not released in Linux unless 1504787 is fixed, since this is a
> regression in internal consistency in Firefox.

I tend to disagree. We don't want to keep inconsistencies between DevTools theme, and users can also use a dark GTK theme with dark scrollbars which look out of place in the DevTools light theme but look good in its dark theme.

IMO any solution should be applied to both theme, and for now on the CSS side we have two options:

1. Use non-GTK scrollbars that match the theme, using scrollbar-color (as implemented in this bug, no change needed).
2. Use GTK scrollbars, that will only match one of the two DevTools theme, leaving users with the responsibility to pick a DevTools theme that matches their GTK theme.

Both solutions are bound to be okay for some users and problematic for others, and I'm not sure we can easily say which is best. I would err on the side of #1 because "inconsistent" is a lesser sin that "sticks out like a sore thumb" in my book, but I agree that it's not a great solution and I would like to see a better solution using GTK subthemes.

Comment 24

[Asif Youssuff]

Attachment: about-home-light-scrollbar.png

> Not necessarily. But scrollbars on Linux are a pain in the arse and different applications or even parts of Firefox try to handle as well as possible. For instance:

> - Chrome uses custom scrollbars instead of the GTK ones (I'm also getting different non-GTK scrollbars in Chrome 69 and Chromium 69; one is a floating scrollbar and the other is a Windows-like scrollbar).

I'm all for referencing Chrome when it comes to webcompat stuff, but I see very little reason most of the time to believe that they have many answers in the chrome design; indeed, I looked at their scrollbars as soon as I started doing some research for this bug, and I was horrified by their scrollbar design. I immediately understood why I had to remove custom CSS styling from a webapp (that applied to Chrome in macOS), because somehow developers found it desirable to emulate the look of Chrome's Windows scrollbars in macOS!

I also understand that Firefox is not Camino, but it *is* the default browser in a couple of major Linux distros, beating out the GNOME Web app - I think it behooves Firefox to try to be a good citizen. 

>If you look at a web page with a light background and devtools with a dark background, you have two very different situations that may call for different solutions. Light GTK scrollbars in the DevTools dark theme, and dark GTK scrollbars in the DevTools light theme, are particularly jarring and can create the same kind of accessibility issue that Yuri reported here (regarding attention deficit disorders).

>I don't disagree with your point and I'm all for consistency, but I want to stress that this is a hard design problem (you have sections of dark UI and light UI in the same application, and may inherit light-or-dark controls from GTK that look out of place in either of those sections, so that makes 4 different situations to account for), and that this is a hard-enough technical problem too (4 situations, can't be fully fixed in CSS, and I haven't explored JS-driven solutions yet but they don't seem straightforward).

I understand the problems here, but when responding to this bug, I found it challenging to even find the dark mode theme in dev tools -- I started by updating my Firefox theme to the dark theme, and was surprised when it didn't update dev tools. 

I wondered why the Firefox theme didn't simply apply to the dev tools theme, but I understood that the designers here desired to be able to have disparate themes across this area of the app. When you break convention, it is pretty much expected to be hard -- I totally understand the desire for differing styling in these areas of Firefox, but to them say "oh it is hard to do this, let's just make our own widgets that are internally inconsistent" isn't solving the problem, it is giving up. That was my essential point in saying that it was internally inconsistent -- not that I want the new styling in both places, but rather that the new styling *if so adept at solving these problems* should simply be rolled out to the entire app. 

>The best solution would probably be what Yuri suggest, i.e. to ask GTK to use a dark or light subtheme and leave the responsibility to provide such subthemes to theme maintainers. Right now we can't do that in CSS, and I'm not sure we can do it in JS efficiently.

Yes, I would hope that is possible, and definitely seems like the best solution. I personally haven't played with the "gtk-application-prefer-dark-theme" preference, but I will note that Firefox allows for "widget.content.gtk-theme-override" per bug 1283086 that allows it to load an arbitrary theme on a content basis, so it seems like Firefox could also do something similar within dev tools, since you know exactly where to override, and which type of theme you prefer. 

>I tend to disagree. We don't want to keep inconsistencies between DevTools theme, and users can also use a dark GTK theme with dark scrollbars which look out of place in the DevTools light theme but look good in its dark theme.

Yes, but this is thinking about this backwards -- 

* why is it a foregone conclusion that there needs to be a dark theme separate from the light theme in dev tools. The whole inconsistency between dark and "light" across Firefox and dev tools is a self imposed one!
* Firefox has its own theme functionality, and if it doesn't attempt to solve this problem, why is dev tools so special that it needs to go off and do its own thing to solve it?

>Both solutions are bound to be okay for some users and problematic for others, and I'm not sure we can easily say which is best. I would err on the side of #1 because "inconsistent" is a lesser sin that "sticks out like a sore thumb" in my book, but I agree that it's not a great solution and I would like to see a better solution using GTK subthemes.

If I navigate to about:home with the Firefox dark theme enabled, the scrollbar sticks out. A solution based on the thinking in this bug would be to replace the scrollbar entirely with something that doesn't resemble my platform scrollbar, because "inconsistent" is a lesser sin that "sticks out like a sore thumb" - although to be fair, this is basically an argument for doing what Chrome does, whole hog -- just use its own scrollbars. 

Maybe it was a bad idea to mention it. I know Firefox isn't Camino, but Chrome's chrome is a big part of the reason I don't use it, even when performance or webcompat in Firefox suffers. 

I don't want to derail the topic (so I won't), but in the light dev tools theme, the new scrollbar represents a regression to users, both in internal consistency and in platform consistency. Why is it better for the light and dark theme scrollbars to be consistent, overriding both internal Firefox consistency and platform consistency, especially when both are coherent in the stable Firefox?

This ticket makes things worse in that scenario, so I'd much rather (if this must be released) this apply to the dark theme only, since dark theme users may indeed prefer that these scrollbars not stick out like a sore thumb.

Comment 25

[Florens Verschelde :fvsch]

> The whole inconsistency between dark and "light" across Firefox and dev tools is a self imposed one!

It was actually requested by users.
The way it's achieved (no syncing at all, rather than syncing + the ability to opt out) is questionable, and could perhaps be improved, but that's a different topic.

> Firefox has its own theme functionality, and if it doesn't attempt to solve this problem, why is dev tools so special that it needs to go off and do its own thing to solve it?

DevTools have scrollbars in the middle of content (e.g. see the Inspector's 3 panel view), which is less often true in the rest of Firefox's UI. That's the main motivation for setting scrollbar colors in DevTools.

Comment 26

[Asif Youssuff]

Spawned bug 1505096 based on:

>The way it's achieved (no syncing at all, rather than syncing + the ability to opt out) is questionable, and could perhaps be improved, but that's a different topic.

Comment 27

[Yuri Khan]

I see the expression “sore thumb” used here. What’s amusing is that I almost used it in my original comment, to refer to the thumb displayed in DevTools in the current (Nightly 64) implementation, in both light and dark DevTools themes.

The fake floating scrollbar used by Firefox 63 in the dark DevTools theme was tolerable. Still wrong (because, hey, non-native widget!), but not rage-inducing.