Add basic support for dark widgets in the non-native theme.
Categories
(Core :: Widget, task)
Tracking
()
People
(Reporter: emilio, Assigned: emilio)
References
Details
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
|
Details | Review |
54.21 KB,
text/plain
|
Details |
Assignee | ||
Comment 1•3 years ago
|
||
For that:
-
Tweak the standin system colors to match the non-native theme.
-
Use system colors for button and field backgrounds.
-
Rename the "should use system colors" bit to "is high contrast",
which is what it really is (specially now that we use system colors
also in non-high-contrast).
Comment 5•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6d22ab00f313
https://hg.mozilla.org/mozilla-central/rev/75280bd24454
https://hg.mozilla.org/mozilla-central/rev/124d1c199d38
Comment 6•3 years ago
|
||
https://hg.mozilla.org/mozilla-central/file/6d22ab00f3133b6760ebca3943dba097eff853c7/dom/canvas/test/test_bug1485266.html#l77
-moz-mac-AlternatePrimaryHighlight
(with RFP or stand-ins) is coded as rgb(63, 63, 63)
but returns rgb(0, 0, 0)
in tests [1]
I does this on windows, mac, and my android nightlies. I couldn't test linux but assume it behaves the same. It is reading the previous value left by
-moz-html-cellhighlighttext
which was dropped but still reports the same as -moz-cellhighlighttext
Is -moz-mac-AlternatePrimaryHighlight
not defined and hooked up yet? TIA
[1] STR
- enable RFP
- https://arkenfox.github.io/TZP/tzp.html#css
- click the
[33]
hyperlink for[stand-in] [-moz-] colors
- open console log
Assignee | ||
Comment 7•3 years ago
|
||
-moz-mac-AlternatePrimaryHighlight
is not hooked up anywhere. It's not a color we support. I'd have to blame to know when it was removed, but we should probably remove it from the test.
Comment 8•3 years ago
|
||
OK, cool. Do you want a bugzilla filed? Also, out of interest, why doesn't this get picked up and the test throw?
Assignee | ||
Comment 9•3 years ago
|
||
Sure. Probably because it's supposed to be the same color as -moz-mac-DisabledToolbarText
which we do support, so the test just carries on.
Comment 10•3 years ago
|
||
Comment 11•3 years ago
|
||
which we do support, so the test just carries on
so the test is flawed, we should create a new element for each one :)
Assignee | ||
Comment 12•3 years ago
•
|
||
Comment on attachment 9244325 [details]
Bug 1734115 - Add basic support for dark form controls to nsNativeBasicTheme. r=mstange,dholbert
Beta/Release Uplift Approval Request
- User impact if declined: Content doesn't use this just yet, but we need it for bug 1733968 to be effective when the OS theme is light and content wants to draw dark widgets.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: bug 1734723 and bug 1735077
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): It's a relatively straight-forward change to a well-tested codepath. Regressions like the two other bugs above are easy to spot and fix.
- String changes made/needed: none
Comment 13•3 years ago
•
|
||
@emilio This needs a rebase patch for beta
Updated•3 years ago
|
Assignee | ||
Comment 14•3 years ago
|
||
Ah, this patch depends on bug 1734009 landing first (checked that that one applies cleanly). Sent a request for that one too.
With that, it needs a minor conflict resolution to account for the Windows' ifdefs in beta, here's the rebased patch with that accounted for.
For convenience, here's a stack of all the 5 patches that have to land on top of current beta: https://treeherder.mozilla.org/jobs?repo=try&revision=0bd7926bac4e50460640c203401620d128b673ea
Comment 15•3 years ago
|
||
Comment on attachment 9244325 [details]
Bug 1734115 - Add basic support for dark form controls to nsNativeBasicTheme. r=mstange,dholbert
Approved for 94.0b6
Comment 16•3 years ago
|
||
bugherder uplift |
Comment hidden (Intermittent Failures Robot) |
Description
•