Closed Bug 1506447 Opened 4 years ago Closed 4 years ago

scrollbar-color results in a black background on macOS Mojave


(Core :: Widget: Cocoa, defect)

Not set



Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 + verified
firefox65 + verified


(Reporter: fvsch, Assigned: xidorn)


(Blocks 1 open bug)


(Keywords: regression)


(4 files)

Using :root { scrollbar-color: ... } on macOS Mojave with Dark Mode enabled results in scrollbars showing up with a fully black background when scrolling.

This affects web content as shown in the attached screenshot.
This may effect Mojave's light mode as well

I've also noticed something similar in DevTools, in the Style Editor or the Debugger's center panel, but not sure it's the same issue.
Component: CSS Parsing and Computation → Widget: Cocoa
Flags: needinfo?(xidorn+moz)
I cannot reproduce this issue on macOS Mojave with either dark mode or light mode.
Flags: needinfo?(xidorn+moz)
Reproduced in this video with Mojave 10.14.1 in Dark Mode, latest Nightly and a fresh profile:

In the first part of the video we can see strange things happening with scrollbars in devtools Style Editor and Debugger, though I'm not sure if this is related to our use of scrollbar-color or not.
In the second part you can see how using scrollbar-color affects the scrollbar's rendering when scrolling.
Thanks for the screencast, that's very helpful. I now know how to reproduce it, and I'll have a look into the issue.
Blocks: mojave, 1460109
Assignee: nobody → xidorn+moz
Blocks: 1498216
This would need uplifting. But the code should be low risk enough.
Pushed by
Check overlay before checking custom scrollbar style in nsNativeThemeCocoa::GetWidgetTransparency. r=spohl
Attached file testcase
Comment on attachment 9027390 [details]
Bug 1506447 - Check overlay before checking custom scrollbar style in nsNativeThemeCocoa::GetWidgetTransparency. r?spohl

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1498216

User impact if declined: Users on macOS Mojave may see problematic scrollbars (as shown in the attachment) when visiting a website using the new scrollbar-color property.

Is this code covered by automated tests?: No

Has the fix been verified in Nightly?: No

Needs manual test from QE?: Yes

If yes, steps to reproduce: On macOS Mojave, ensure that scrollbar is autohidden, then open the testcase attachment 9028594 [details] and scroll with touchpad. The scrollbar should not be black. This may be more reproducible with dark mode.

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): This change only touches code path used by the new feature, which isn't widely used yet, so it's unlikely to break any existing stuff.

String changes made/needed:
Attachment #9027390 - Flags: approval-mozilla-beta?
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Verified the fix on the Nightly 12-01 build.
Comment on attachment 9027390 [details]
Bug 1506447 - Check overlay before checking custom scrollbar style in nsNativeThemeCocoa::GetWidgetTransparency. r?spohl

Fix for new macOS scrollbar issue, verified in nightly, let's uplift. 

[Triage Comment]
Attachment #9027390 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I verified this on Mac OS X 10.14 on FF Nightly 65.0a1(2018-12-02) and I can't reproduce the issue. I will verify it on Beta after the uplift.
I also tested this on iMac OS X 10.14 with FF Nightly 65.0a1(2018-12-02) and I think there is a problem, please see the attached print screen with the actual result on iMac. Please note that on MacBook this issue is not displayed on the same Firefox version. 
Xidorn can you please take a look? Thanks
Flags: needinfo?(xidorn+moz)
Scrollbar with blue track and cyan thumb is expected when overlay scrollbar is not used in the given test case.
Flags: needinfo?(xidorn+moz)
I tested this on MacBook 10.14 with FF Beta 64.0b14 and I can confirm the fact that this issue is fixed.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.