Expose both light and dark system theme colors to chrome UI
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox91 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
Details
Attachments
(3 files)
In the longer term, perhaps this should be done with the color-scheme
CSS property. But for now exposing the two sets of system colors via a chrome function seems easy enough.
Assignee | ||
Comment 1•3 years ago
|
||
Assignee | ||
Comment 2•3 years ago
|
||
Depends on D117416
Assignee | ||
Updated•3 years ago
|
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/cca441d5cc81 Add an internal -moz-system-color() function to expose both light and dark system colors. r=jwatt https://hg.mozilla.org/integration/autoland/rev/44d7bcefdc8b Expose text selection foreground / background colors to chrome code. r=jwatt
Assignee | ||
Comment 4•3 years ago
|
||
This shouldn't have a meaningful behavior change, as the default link
color right now is taken from the browser.anchor_color pref.
Returning this color from -moz-nativehyperlinktext makes no sense, and
it wasn't being handled correctly before: On GeckoView this color was
transparent.
The other patches in this bug cause NS_SAME_AS_FOREGROUND_COLOR to be
handled correctly, as currentColor, and cause a test failure on android
which asserts that -moz-nativehyperlinktext doesn't return the initial
value.
This color is supposed to be internal, but is has been historically
exposed to the web. Will try to unship these on a follow-up bug.
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/b6ab0521071e Don't use NS_SAME_AS_FOREGROUND_COLOR on android for -moz-nativehyperlinktext color. r=agi a=orange
Comment 6•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/cca441d5cc81
https://hg.mozilla.org/mozilla-central/rev/44d7bcefdc8b
https://hg.mozilla.org/mozilla-central/rev/b6ab0521071e
Description
•