Open Bug 1473298 Opened 6 years ago Updated 2 years ago

Make new native scrollbar darker on Dark Theme

Categories

(DevTools :: Framework, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: nachtigall, Unassigned)

References

Details

Attachments

(1 file)

I ran mozregression and landed at intentionally implemented bug 1464785 :) Scanning over the discussion I can see the reasoning for using Native scrollbars over Floating ones. But two questions / concerns: 1. Could you please make theme darker? The new scrollbars are way lighter and distracting (into your eyes) then the old ones. See attached document. I guess this is because the old ones also had an `opacity`/transparency which made them look darker and the dark background AFAIU you can use scrollbar-face-color and scrollbar-track-color, so I think this would be achievable easily, right? (2. The new native scrollbar take up way more space. Can they be made thinner? I guess this is not possible, but look at the attached screenshot to see the difference. Just to make you aware...)
NI'ing Violasong (hope I got the email right?) to maybe come up with some different colors or comment on it. fwiw, I am very used to the old scrollbars, so maybe i am just biased or too much used to it...
Flags: needinfo?(victoria)
Blocks: 1464785
Also compare to Chrome's Dark DevTool Theme. It is darker plus also the Up ^ and Down v triangles are removed (in the main browser they are present): https://imgur.com/a/QveeCIT Here is Edge: It has no Dark theme, but notice that the scrollbars are much narrower: https://imgur.com/a/h4SzeCO But the best is VSCode where scrollbars are translucent (so Code in background is shown) and they only show when you are the the corresponding window: https://imgur.com/a/awGqYRz I guess that's not possible because it is not a 'native' scrollbar but a floating overlay or something, but it's the best UX for developers imho. Just fyi. BTW, also has no Up ^ or Down v triangles.
Thanks Jens for the great write up and examples from other browsers! (Also for some reason this whole bug made me laugh a lot, I think due to the sincere tone as well as the general mirth of software design, so thanks for that as well :D) Yes, I agree the scrollbar should be both darker and narrower. I think the main use case for devs is to use a scroll wheel so it doesn't have to be as visible as e.g. a button. The translucent style would be great if it's possible. Two other things I'm wondering: Is rounded ends possible? Also, are the arrow buttons necessary? (I'm tempted to say no since Mac native UI (and apparently Edge?) don't have them anymore, but maybe they're important in some situation I'm not aware of?)
Flags: needinfo?(victoria)
So, making them darker: no problem at all. We can do that very easily right now because we can change both the track and thumb colors. Making them translucent: I don't think we can do that. Right now if you make scrollbar colors transparent, then the native scrollbar colors show through. Generally changing their appearance (rounded corner, removing arrows, making them narrowers): that would basically mean undoing the changes in bug 1464785 which we did because of this RFC https://github.com/devtools-html/rfcs/issues/27 where the main point was, in fact, to make our scrollbars consistent with the OS you were running Firefox on. The whole goal was to use the OS native scrollbars (just making their colors match our theme) so they would feel right, just like scrollbars in other apps like your window explorer. So I think we should address the concern about the colors here. Right now those colors are the following ones: scrollbar-face-color: var(--theme-body-color-inactive) --> gray-40 scrollbar-track-color: var(--theme-splitter-color) --> #3c3c3d Victoria, do you have other suggestions for better colors we could use here? I would suggest: scrollbar-face-color: var(--theme-splitter-color) scrollbar-track-color: var(--theme-body-background)
Flags: needinfo?(victoria)
Thanks Patrick for the info - I hadn't actually seen this in my own Nightly yet since I was using the light theme, but I see now what you mean about the OS native rounded corners, etc. Aside from the brightness, it looks great! I agree about var(--theme-body-background) for track color. For face color, I think the splitter color is a bit too subtle. I experimented with this in Sketch and would suggest --theme-content-color3 (#58575c), with Gray 50 on hover/focus. Approximation of how this would look: https://mozilla.invisionapp.com/share/VUMPRWMHK6C (normal on left, hovered on right)
Flags: needinfo?(victoria)
See Also: → 1475033
Severity: normal → enhancement
Priority: -- → P3
Jens, Bug 1464348 updated the dark theme colors to fix some contrast issues DevTools and it looks like it made the scrollbars darker. Can you test a recent build? Maybe we can close this bug as a duplicate?
Flags: needinfo?(nachtigall)
See Also: → 1464348
Yeah, the “inactive” color was too contrasted in the dark theme (it was okay in the light theme) and we fixed that. So any code that truly wanted an “inactive” color finally got one in the dark theme. dark-theme.css looks like: :root[platform="win"], :root[platform="mac"] { /* Set colors for native scrollbars on Windows dark theme */ /* Other platforms support for scrollbar theming is Bug 1460109 */ scrollbar-face-color: var(--theme-body-color-inactive); scrollbar-track-color: var(--theme-splitter-color); } I would recommend setting Photon Grey colors explicitly here, rather than depending on a variable intended for text color and which we might still tweak in the future. So, something like: :root[platform="win"], :root[platform="mac"] { /* Set colors for native scrollbars on Windows dark theme */ /* Other platforms support for scrollbar theming is Bug 1460109 */ scrollbar-face-color: var(--grey-40); scrollbar-track-color: var(--theme-splitter-color); } Or maybe create a new --theme variable for the scrollbar thumb color.
`scrollbar-face-color` doesn't seem to impact the scrollbar thumb on macOS. In my tests it's always pure white at 50% opacity (even when changing that property or all other colors to red or lime). This style seems to come from: thumb[orient="vertical"] { -moz-appearance: scrollbarthumb-vertical; }
(In reply to Florens Verschelde from comment #8) > `scrollbar-face-color` doesn't seem to impact the scrollbar thumb on macOS. > In my tests it's always pure white at 50% opacity (even when changing that > property or all other colors to red or lime). > > This style seems to come from: > > thumb[orient="vertical"] { > -moz-appearance: scrollbarthumb-vertical; > } You must be testing floating scrollbars. If the properties did not work as expected, you would see the very bright default scrollbars, the same as on the light theme. To force non-floating scrollbars on OSX, you must set "Always" in "System Preferences > General > Show scrollbars"
(In reply to Julian Descottes [:jdescottes][:julian] from comment #6) > Jens, Bug 1464348 updated the dark theme colors to fix some contrast issues > DevTools and it looks like it made the scrollbars darker. Can you test a > recent build? Maybe we can close this bug as a duplicate? Looks better but still not like prototyped by Victoria (see comment 5 in reply to comment 4). According to this (see also link in her comment) it should be: scrollbar-face-color: var(--theme-content-color3) scrollbar-face-color::hover: gray-50 scrollbar-track-color: var(--theme-body-background) At the moment it is brighter: #737373 for scrollbar-face-color, track-color is still #3c3c3d. (Do not know the var names, just checked with a color picker).
Flags: needinfo?(nachtigall)
Thanks Jens for catching this! However, now that I'm seeing my mockup again, I think the current Nightly version is actually better, in following the theme of text being brightened across all the tools. :) It would be nice to have a hover state of slightly brighter, similar to MacOS light mode's hover effect (I think gray40 would be too bright but I think we have a variable or two between 40 and 50).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: