Scrollbar color-scheme detection fails to detect opaque light `<body>` gradient completely covering dark root background
Categories
(Core :: Widget, defect)
Tracking
()
People
(Reporter: oss, Assigned: spohl)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files, 1 obsolete file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36
Steps to reproduce:
- Visit the iframe section of the attached reproduction
- Observe scrollbars are dark themed
Actual results:
Scrollbars are dark themed, while WebKit and Blink render them system color themed, just like regular scroll containers.
Expected results:
Scrollbars should have the same color as normal divs or top level window root.
PS: When testing, make sure to enable "classic" scrollbar style (aka. "always" on OSX).
|
||
Comment 2•3 months ago
|
||
Regression window (Windows11 OS dark mode and enabled Always show scrollbars):
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=a5ce805152fe2d4a4603eb39121b03c3a1886afd&tochange=68918f51531005ca08df92f6ab16c23329e0123e
Triggered by: Bug 1710324
|
|
||
Updated•3 months ago
|
|
Assignee | |
Updated•3 months ago
|
|
|
Assignee | |
Comment 3•3 months ago
|
||
ColorSchemeForWidget routes scrollbar parts through
IsDarkBackgroundForScrollbar, which inspects the effective background
under the scrolled frame and themes the scrollbar dark on dark
backgrounds. Applied to a nested document, the heuristic walks the
iframe's own page (its <html>/<body>) and themes the scrollbar to
match — even though the scrollbar visually belongs to the embedder's
chrome, not the embedded content.
This surfaces clearly when an iframe sets html { background: #222 }
on an otherwise-light embedding page (the bug's reproduction): the
iframe's root scrollbar themes dark while every other scrollbar on
the page (top-level root, divs with overflow) themes light, which
matches what WebKit and Blink do for the same content.
When the scrolled frame we resolved is the root scroll container of a
sub-document, redirect detection to the embedder's iframe element
frame in the outer document. FindEffectiveBackgroundColor then walks
from there — through the embedder's CSS rules (e.g., the testbench's
iframe { background: white } rule) and up the outer document — and
returns a color that reflects the chrome the scrollbar actually sits
in.
Preserved behavior:
- Top-level scrollbars: IsRootContentDocumentInProcess returns
true, so the new branch is skipped and the heuristic runs as
before on the top-level page. - Inner div scrollbars (e.g., a
<div style="overflow: scroll">
inside an iframe): scrollContainerFrame is not the doc's root
scroll, branch skipped — the heuristic still runs on the div's
own background. - XUL
<tree>and other widgets that don't have a scroll
container: scrollContainerFrame is null, branch never reached.
The fix is in the widget layer rather than the layout layer because
the right starting point for "what's behind this scrollbar visually"
is a widget concern — FindEffectiveBackgroundColor itself is still a
faithful query on the frame it's given.
|
||
Updated•3 months ago
|
|
|
Assignee | |
Updated•3 months ago
|
|
|
Assignee | |
Updated•3 months ago
|
|
||
Comment 4•3 months ago
|
||
This has nothing to do with subdocuments. the <body> has a gradient background that we can't reason about. Giving it a background-color: white; or so in the original test-case will get the wanted behavior.
The issue is that our background-color-scheme detection only looks at background-color, not background-image (which is expected, it's hard to reason about gradients or arbitrary images).
I think this is bordering WONTFIX tbh, but we could try to fix it for simple opaque gradients where all color stops match the desired scheme, or return the default background-color for opaque background-images, or so...
|
|
||
Updated•3 months ago
|
|
|
||
Updated•3 months ago
|
|
|
||
Updated•2 months ago
|
|
|
||
Comment 5•2 months ago
|
||
Curious, did you find in a real website? The issue here is that your iframes have a dark background-color which is completely obscured by the <body> background-image. I'm not convinced we should change our behavior here, see the discussion in https://bugzilla.mozilla.org/attachment.cgi?id=9575309
Other browsers don't have heuristics to theme the scrollbars light / dark. We now have the color-scheme property, and we could implement something like that, but I'm not convinced it'd be a net benefit for real websites.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #5)
Curious, did you find in a real website? The issue here is that your iframes have a dark background-color which is completely obscured by the
<body>background-image. I'm not convinced we should change our behavior here, see the discussion in https://bugzilla.mozilla.org/attachment.cgi?id=9575309Other browsers don't have heuristics to theme the scrollbars light / dark. We now have the
color-schemeproperty, and we could implement something like that, but I'm not convinced it'd be a net benefit for real websites.
No, I found it during interop testing for scrollbar(-gutter) positioning in various render scenarios. I was scaffolding a bunch of test benches with Gemini and it just so happened to style one like that, prompting me to raise the issue.
I'm ok with closing this one as wont fix.
|
|
Assignee | |
Comment 7•2 months ago
|
||
Thanks, Emilio, for all the feedback. Closing.
|
|
||
Updated•2 months ago
|
Description
•