1458426 - Overriding colors makes Preferences lists less usable (option under cursor is white-on-white)

Status: RESOLVED WORKSFORME

(Firefox :: Settings UI, defect, P1)

Description

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

STR:
- Start Firefox with fresh profile
- Go to about:preferences
- Under "Fonts & Colors", press "Colors..."
- Under "Override the colors[...]", select "Always"
- Press "OK"

Now in all drop-down lists (e.g., Default font, or Colors->Override) the option under the mouse is invisible (white-on-white).

I would expect Preferences to survive their own setting changes. :-)


(Found while trying to reproduce bug 1430969, I don't think it's the same issue but I'm leaving this note in case it is.)

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey gerald,

I'm not seeing this on macOS. Are you on Windows?

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Confirmed via mozregression on Windows that this was regressed by https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5aa5875856638063e463cfcd2b37619192337ba4&tochange=4118a23fa0b3edbebcc129a811a05ec5067f603c

[Tracking Requested - why for this release]:
Potentially leaves Preferences in a semi-broken state. May be too late for 60 but I didn't want this to go unnoticed if there was an easy fix.

Comment 3

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

(In reply to Mike Conley (:mconley) (:⚙️) (Totally backlogged on reviews and needinfos) from comment #1)
> I'm not seeing this on macOS. Are you on Windows?

I'm seeing it in Nightly on both Mac 10.13.4 and Windows 10.0.17134, with default color-related system and browser settings.

Comment 4

[Mike Taylor [:miketaylr]]

Attachment: screenshot on mac

Yeah, seems pretty bad.

Comment 5

[Julien Cristau [:jcristau] (back April 22)]

Sorry, meant to type a comment.  Joe, if Brian is busy can you find someone to work on this?

Comment 6

[Joe Walker [:jwalker]]

Maybe there is an easy fix that Brian knows about, but long term, I don't think themes should be a browser architecture thing, it's probably more front-end, so ni? :dolske

Comment 7

[Brian Grinstead [:bgrins]]

I did look into this last week but it was fairly hard to inspect the styles and then I was confused by what I was seeing in the computed styles, so didn't come to a conclusion. I'll share what I've found when looking into it though:

- The active state is white text on white background but it occasionally swiches back to black text once you hover on other nodes or otherwise try to inspect it. In both states the 'color' seems to be `var(--in-content-selected-text)` which is only ever set to white (https://searchfox.org/mozilla-central/search?q=in-content-selected-text&path=), so I'm not sure how it ends up ever resolving to black (I'll attach screenshots to show computed styles). There's a _moz-menuactive attribute that looks suspicious since the 'white' state has it and the 'black' state doesn't.

- The fact that the styles were resolving to the same variable made me think it may be a -moz-appearance rule that's changing instead, but I haven't seen a change in computed styles.

- Unfortunately I haven't been able to effectively simulate the hover state to debug that.

Some notes about how I was able to finally inspect things in case someone else wants to check locally or confirm what I'm seeing:

* `--setpref ui.popup.disable_autohide=true`
* Open preferences and set override colors to always as per Comment 0
* Save the subdialog
* Open Inspector
* Open the "Default font" dropdown on the page
* Type 'default (times' into the search field and press Enter once. Look through the DOM tree to find the menupopup below and expand it, then the <xul:scrollbox>, then the <xul:box> below it. Doing this manually allows you to dodge an inspector bug due to XBL anon content (bug 1360072) which for whatever reason seems super frequent in this case
* Now you can click through the menuitems in the popup to inspect

Comment 8

[Brian Grinstead [:bgrins]]

Attachment: initial-active-white-on-white.png

This is the initial UI when opening the dropdown (before it changes to black text). The computed color style is expanded.

Comment 9

[Brian Grinstead [:bgrins]]

Attachment: active-state-after-hovering-around-black-on-white.png

This is a state that the UI 'snaps' to after mousing around / inspecting styles. Notice that the applied 'color' is still the same white variable, but the resolved color value is black.

Comment 10

[Brian Grinstead [:bgrins]]

Just confirmed that manually adding _moz-menuactive=true will switch to the 'white text on white background' behavior on any menu items, even non-active ones

Comment 11

[Brian Grinstead [:bgrins]]

(In reply to Brian Grinstead [:bgrins] from comment #10)
> Just confirmed that manually adding _moz-menuactive=true will switch to the
> 'white text on white background' behavior on any menu items, even non-active
> ones

Oh, and hovering menuitems sets `_moz-menuactive=true` on the hovered node. Still not sure why non _moz-menuactive menuitems don't have white text, but it at least explains why the bug is also affecting hovered nodes.

Comment 12

[Brian Grinstead [:bgrins]]

Attachment: hovering-active-menuitems.gif

This might give a clearer picture of the confusion described in Comment 7. When hovering the node, the computed rules don't change but the resolved color changes from white to black.

The background color also gets set when hovered but removing that doesn't have any effect on the text color.

Comment 13

[Brian Grinstead [:bgrins]]

And both resolved text colors seem wrong, since `--in-content-text-color` should be #0c0c0d as per: https://searchfox.org/mozilla-central/rev/a85db9e29eb3f022dbaf8b9a6390ecbacf51e7dd/toolkit/themes/shared/in-content/common.inc.css#12

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Brian, are you still working on this? We've only got about two weeks left for fixes to land in time for 61.

Comment 15

[Brian Grinstead [:bgrins]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #14)
> Brian, are you still working on this? We've only got about two weeks left
> for fixes to land in time for 61.

I'm haven't been actively looking at it - Comment 7-13 summarize the current state and how to debug further. I can take another pass at it, but I'd appreciate if someone else could look and see if I'm missing something obvious.

One question I ran into when looking at this is: do we intend to have this setting apply to about:preferences and other in-content chrome pages? I notice this setting causes lots of UI problems in other pages as well (in about:config, the new tab page, among other places). This can be easily confirmed by doing `./mach run --temp-profile --setpref browser.display.document_color_use=2`.

There's a condition when the pref value is set to 2 that check `mUseDocumentColors = isChromeDocShell || mIsChromeOriginImage`, which made me think that we didn't want this to apply to chrome, but I guess it's not true in this case: https://searchfox.org/mozilla-central/rev/8affe6e83188787eb61fe0528eeb6eef6081ba06/layout/base/nsPresContext.cpp#520.

Comment 16

[Brian Grinstead [:bgrins]]

Attachment: new-tab-page-with-setting-applied.png

An example of the UI issues mentioned in the new tab page

Comment 17

[Brian Grinstead [:bgrins]]

My best guess is that with the menu colors now being UA styles they don't get ignored anymore when mUseDocumentColors is false, but that the colors from XBL styles / preshints were ignored. It's hard to debug from the frontend because devtools seem to be unaware that certain styles are ignored.

Evidence for that is that if I navigate to a web page with the setting applied, the computed style showing the color rendered on the screen, but the expanded rules act as if something else should apply - just as in attachment 8975571 [details] / Comment 13.

We've also discussed making these sheets not UA sheets but adding a new cascade level more like XBL in Bug 1457907 so that !important rules could be overridden. But adding a new cascade level introduces complexity in the platform that wouldn't be removable until we moved all these sheets to document / Shadow DOM sheets, which as pointed out in https://bugzilla.mozilla.org/show_bug.cgi?id=1457907#c7 may not get prioritized.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

(In reply to Brian Grinstead [:bgrins] from comment #17)
> My best guess is that with the menu colors now being UA styles they don't
> get ignored anymore when mUseDocumentColors is false, but that the colors
> from XBL styles / preshints were ignored. It's hard to debug from the
> frontend because devtools seem to be unaware that certain styles are ignored.

Yes, this is exactly what's happening. This is the condition that triggers it:

  https://searchfox.org/mozilla-central/rev/2aa42f2cab4a110edf21dd7281ac23a1ea8901f9/servo/components/style/properties/properties.mako.rs#1049

Comment 19

[:Gijs (he/him)]

(In reply to Brian Grinstead [:bgrins] from comment #15)
> One question I ran into when looking at this is: do we intend to have this
> setting apply to about:preferences and other in-content chrome pages?

In principle, yes.

> I
> notice this setting causes lots of UI problems in other pages as well (in
> about:config, the new tab page, among other places). This can be easily
> confirmed by doing `./mach run --temp-profile --setpref
> browser.display.document_color_use=2`.

The new tab page is covered by bug 1445266.

Basically, setting this to "always" does the same as enabling a high contrast theme in Windows (and having the setting be "only when using a high contrast theme", which is the default). Our support for it is... not as good as it should be. But we do want to support it - the "point" is that some people need high contrast mode (HCM) to reasonably use a computer, and we try to make it possible for them to use the web when they do that.


> There's a condition when the pref value is set to 2 that check
> `mUseDocumentColors = isChromeDocShell || mIsChromeOriginImage`, which made
> me think that we didn't want this to apply to chrome, but I guess it's not
> true in this case:
> https://searchfox.org/mozilla-central/rev/
> 8affe6e83188787eb61fe0528eeb6eef6081ba06/layout/base/nsPresContext.cpp#520.

Right, we don't apply it to chrome docshells, because in theory the XUL should be obeying windows theming / high contrast theming anyway (and large parts of it, like the toolbar foreground/background colors, do so), and it may need to use document/author CSS to make that happen, but using system color references.

The in-content pages largely don't use system colours and to make them "fit" with HCM, they should just have the HCM colors and styling applied. AFAIK this largely worked OK for about:preferences until recently.

(In reply to Emilio Cobos Álvarez [:emilio] from comment #18)
> (In reply to Brian Grinstead [:bgrins] from comment #17)
> > My best guess is that with the menu colors now being UA styles they don't
> > get ignored anymore when mUseDocumentColors is false, but that the colors
> > from XBL styles / preshints were ignored. It's hard to debug from the
> > frontend because devtools seem to be unaware that certain styles are ignored.
> 
> Yes, this is exactly what's happening. This is the condition that triggers
> it:
> 
>  
> https://searchfox.org/mozilla-central/rev/
> 2aa42f2cab4a110edf21dd7281ac23a1ea8901f9/servo/components/style/properties/
> properties.mako.rs#1049

So my understanding based on this is that the background color is set using something that gets ignored, but the foreground color is set using something that doesn't get ignored? I would have expected the background to be set using a system color, in a UA sheet that doesn't get ignored... and that would presumably fix this issue? (ni for this)

FWIW, far be it from me to pretend that the current state of our HCM support is great. It very much isn't (e.g. bug 1430969, bug 1266172, open deps in the tree for bug 343205, etc. , but so far fixing it hasn't had any priority assigned to it so it hasn't happened.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> So my understanding based on this is that the background color is set using something that gets ignored,
> but the foreground color is set using something that doesn't get ignored?

Or vice versa, yes.

Comment 21

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1458426 - Disable custom theming for selected menuitems when document_color_use is set to Always or when High Contrast Mode is enabled.

This is a simple patch that we could uplift if desired as it will just disable a couple CSS rules in this situation. I have tested this with document_color_use=2 and separately with High Contrast mode enabled on Windows.

Review commit: https://reviewboard.mozilla.org/r/247966/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/247966/

Comment 22

[Dão Gottwald [:dao]]

Comment on attachment 8981953 [details]
Bug 1458426 - Disable custom theming for selected menuitems when document_color_use is set to Always or when High Contrast Mode is enabled.

https://reviewboard.mozilla.org/r/247966/#review254088

This doesn't seem complete, as enabling high contrast mode doesn't set this pref. Am I missing something?

Comment 23

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8981953 [details]
Bug 1458426 - Disable custom theming for selected menuitems when document_color_use is set to Always or when High Contrast Mode is enabled.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/247966/diff/1-2/

Comment 24

[Dão Gottwald [:dao]]

This is becoming increasingly ugly and it seems hard to believe that there's no better fix that can be uplifted.

bgrins, can bug 1420229 be reverted?

Comment 25

[Brian Grinstead [:bgrins]]

(In reply to Dão Gottwald [::dao] from comment #24)
> This is becoming increasingly ugly and it seems hard to believe that there's
> no better fix that can be uplifted.
> 
> bgrins, can bug 1420229 be reverted?

No, not easily. We have been discussing other options that will help avoid this problem for all sheets, including a new cascade just after UA but treated as author sheets or rewriting CSS to use Shadow DOM (https://bugzilla.mozilla.org/show_bug.cgi?id=1457907#c23). I doubt either of those would be upliftable.

Comment 26

[Brian Grinstead [:bgrins]]

(In reply to :Gijs (no internet until June 6; he/him) from comment #19)
> > There's a condition when the pref value is set to 2 that check
> > `mUseDocumentColors = isChromeDocShell || mIsChromeOriginImage`, which made
> > me think that we didn't want this to apply to chrome, but I guess it's not
> > true in this case:
> > https://searchfox.org/mozilla-central/rev/
> > 8affe6e83188787eb61fe0528eeb6eef6081ba06/layout/base/nsPresContext.cpp#520.
> 
> Right, we don't apply it to chrome docshells, because in theory the XUL
> should be obeying windows theming / high contrast theming anyway (and large
> parts of it, like the toolbar foreground/background colors, do so), and it
> may need to use document/author CSS to make that happen, but using system
> color references.
> 
> The in-content pages largely don't use system colours and to make them "fit"
> with HCM, they should just have the HCM colors and styling applied. AFAIK
> this largely worked OK for about:preferences until recently.

Maybe I'm misunderstanding, but why is about:preferences not in a chrome doc shell? Could we loosen this condition to include about pages?

Comment 27

[Dão Gottwald [:dao]]

Comment on attachment 8981953 [details]
Bug 1458426 - Disable custom theming for selected menuitems when document_color_use is set to Always or when High Contrast Mode is enabled.

https://reviewboard.mozilla.org/r/247966/#review254708

Actually this doesn't even fix the bug over here on Linux, because the problematic rules seem to be in menu.css, not common.inc.css.

Comment 28

[Brian Grinstead [:bgrins]]

(In reply to Dão Gottwald [::dao] from comment #27)
> Comment on attachment 8981953 [details]
> Bug 1458426 - Disable custom theming for selected menuitems when
> document_color_use is set to Always or when High Contrast Mode is enabled.
> 
> https://reviewboard.mozilla.org/r/247966/#review254708
> 
> Actually this doesn't even fix the bug over here on Linux, because the
> problematic rules seem to be in menu.css, not common.inc.css.

What are the problematic rules?

Comment 29

[Brian Grinstead [:bgrins]]

If do we end up needing to override rules I wonder if it'd be reasonable to add a new -moz pseudo class that matches when document colors are overridden so we don't need to keep track of the pref / HCM for individual documents.

Comment 30

[Dão Gottwald [:dao]]

(In reply to Brian Grinstead [:bgrins] from comment #28)
> (In reply to Dão Gottwald [::dao] from comment #27)
> > Comment on attachment 8981953 [details]
> > Bug 1458426 - Disable custom theming for selected menuitems when
> > document_color_use is set to Always or when High Contrast Mode is enabled.
> > 
> > https://reviewboard.mozilla.org/r/247966/#review254708
> > 
> > Actually this doesn't even fix the bug over here on Linux, because the
> > problematic rules seem to be in menu.css, not common.inc.css.
> 
> What are the problematic rules?

On Linux at least: https://searchfox.org/mozilla-central/rev/38bcf897f1fa19c1eba441a611cf309482e0d6e5/toolkit/themes/linux/global/menu.css#19,31-32

Comment 31

[Brian Grinstead [:bgrins]]

(In reply to Dão Gottwald [::dao] from comment #30)
> (In reply to Brian Grinstead [:bgrins] from comment #28)
> > (In reply to Dão Gottwald [::dao] from comment #27)
> > > Comment on attachment 8981953 [details]
> > > Bug 1458426 - Disable custom theming for selected menuitems when
> > > document_color_use is set to Always or when High Contrast Mode is enabled.
> > > 
> > > https://reviewboard.mozilla.org/r/247966/#review254708
> > > 
> > > Actually this doesn't even fix the bug over here on Linux, because the
> > > problematic rules seem to be in menu.css, not common.inc.css.
> > 
> > What are the problematic rules?
> 
> On Linux at least:
> https://searchfox.org/mozilla-central/rev/
> 38bcf897f1fa19c1eba441a611cf309482e0d6e5/toolkit/themes/linux/global/menu.
> css#19,31-32

Those are using system colors, so I thought they should be OK with the high contrast theme. For the active menuitem, shouldn't having `color: -moz-menuhovertext` and `background-color: -moz-menuhover;` work fine?

Comment 32

[Dão Gottwald [:dao]]

(In reply to Brian Grinstead [:bgrins] from comment #31)
> > > What are the problematic rules?
> > 
> > On Linux at least:
> > https://searchfox.org/mozilla-central/rev/
> > 38bcf897f1fa19c1eba441a611cf309482e0d6e5/toolkit/themes/linux/global/menu.
> > css#19,31-32
> 
> Those are using system colors, so I thought they should be OK with the high
> contrast theme.

I didn't use a high contrast theme there, just changed color settings as per comment 0.

> For the active menuitem, shouldn't having `color:
> -moz-menuhovertext` and `background-color: -moz-menuhover;` work fine?

It looks like only the color is applied and not the background, or something like that. I think the expectation here is that both should be dropped when used in the content area with document colors disabled.

Comment 33

[Brian Grinstead [:bgrins]]

(In reply to Dão Gottwald [::dao] from comment #32)
> (In reply to Brian Grinstead [:bgrins] from comment #31)
> > > > What are the problematic rules?
> > > 
> > > On Linux at least:
> > > https://searchfox.org/mozilla-central/rev/
> > > 38bcf897f1fa19c1eba441a611cf309482e0d6e5/toolkit/themes/linux/global/menu.
> > > css#19,31-32
> > 
> > Those are using system colors, so I thought they should be OK with the high
> > contrast theme.
> 
> I didn't use a high contrast theme there, just changed color settings as per
> comment 0.
> 
> > For the active menuitem, shouldn't having `color:
> > -moz-menuhovertext` and `background-color: -moz-menuhover;` work fine?
> 
> It looks like only the color is applied and not the background, or something
> like that. I think the expectation here is that both should be dropped when
> used in the content area with document colors disabled.

My expectation was that both colors should be applied, not dropped, when document colors are disabled. Is there a reason it'd be better to drop them?

Comment 34

[Dão Gottwald [:dao]]

(In reply to Brian Grinstead [:bgrins] from comment #33)
> (In reply to Dão Gottwald [::dao] from comment #32)
> > (In reply to Brian Grinstead [:bgrins] from comment #31)
> > > > > What are the problematic rules?
> > > > 
> > > > On Linux at least:
> > > > https://searchfox.org/mozilla-central/rev/
> > > > 38bcf897f1fa19c1eba441a611cf309482e0d6e5/toolkit/themes/linux/global/menu.
> > > > css#19,31-32
> > > 
> > > Those are using system colors, so I thought they should be OK with the high
> > > contrast theme.
> > 
> > I didn't use a high contrast theme there, just changed color settings as per
> > comment 0.
> > 
> > > For the active menuitem, shouldn't having `color:
> > > -moz-menuhovertext` and `background-color: -moz-menuhover;` work fine?
> > 
> > It looks like only the color is applied and not the background, or something
> > like that. I think the expectation here is that both should be dropped when
> > used in the content area with document colors disabled.
> 
> My expectation was that both colors should be applied, not dropped, when
> document colors are disabled. Is there a reason it'd be better to drop them?

I guess that's an option too given that you also still get OS-styled widgets in web content with user-specified colors and document colors disabled.

Maybe the problem is that these are still applied with document colors disabled:

https://searchfox.org/mozilla-central/rev/38bcf897f1fa19c1eba441a611cf309482e0d6e5/toolkit/themes/shared/in-content/common.inc.css#402,412

Comment 35

[Jared Wein [:jaws] (please needinfo? me)]

Based on comment 34, I tried undoing my previous changes to common.inc.css and adding the following rules but this doesn't seem sufficient:
```css
:root[document_color_use] xul|menulist > xul|menupopup,
:root[document_color_use] xul|button[type="menu"] > xul|menupopup {
  -moz-appearance: menupopup !important;
}

:root[document_color_use] xul|menulist > xul|menupopup > xul|menu,
:root[document_color_use] xul|button[type="menu"] > xul|menupopup > xul|menu {
  -moz-appearance: menu !important;
}

:root[document_color_use] xul|menulist > xul|menupopup > xul|menuitem,
:root[document_color_use] xul|button[type="menu"] > xul|menupopup > xul|menuitem {
  -moz-appearance: menuitem !important;
}
```

If `background-color` is set, as the rules above this block will do, then it seems that setting -moz-appearance is ignored. I could prefix `root:not([document_color_use]) ` to the selectors in toolkit/themes/linux/global/menu.css to fix this issue on Linux. I don't think we should try for a deeper fix because we will need a patch that can be uplifted. It sounds like the correct long term fix here is to add a new type of style sheet, but that won't happen soon.

Comment 36

[Dão Gottwald [:dao]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #35)
> If `background-color` is set, as the rules above this block will do, then it
> seems that setting -moz-appearance is ignored.

I can't seem to reproduce this (with the browser toolbox), and border and background shouldn't override -moz-appearance in chrome stylesheets.

> I could prefix
> `root:not([document_color_use]) ` to the selectors in
> toolkit/themes/linux/global/menu.css to fix this issue on Linux. I don't
> think we should try for a deeper fix because we will need a patch that can
> be uplifted. It sounds like the correct long term fix here is to add a new
> type of style sheet, but that won't happen soon.

This sounds a bit backwards. Rather than assuming that the right fix isn't upliftable and landing a hack and then probably forgetting about this until the next time it hits us, we should look for the right fix right now, see if we can uplift that, and if that doesn't work out resort to a hack.

bz, continuing from comment 34, would it be reasonable and feasible to ignore -moz-appearance in chrome (not UA) sheets with document colors disabled?

Comment 37

[Boris Zbarsky [:bzbarsky]]

I don't actually know the answer offhand for stylo.  Emilio, do you?

Comment 38

[Emilio Cobos Álvarez (:emilio)]

The information we had at the point of making the decision[1] is:

 * Property id.
 * Origin (User / UserAgent / Author).
 * pseudo-element

We also have a bunch of other stuff like element, etc, should it be needed.

I assume the reason this doesn't work is because those chrome rules _are_ UA rules now, right?

If so, we may be able to store a bit in style rules or rule nodes tells whether they came from chrome sheets and use it... Though not sure how trivial would that be.

Dao, did I get that right? (that is, what you're trying to ignore are UA rules, they just also happen to be chrome rules).

[1]: https://searchfox.org/mozilla-central/rev/3737701cfab93ccea04c0e9cab211ad10f931d87/servo/components/style/properties/properties.mako.rs#1040

Comment 39

[Dão Gottwald [:dao]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #38)
> The information we had at the point of making the decision[1] is:
> 
>  * Property id.
>  * Origin (User / UserAgent / Author).
>  * pseudo-element
> 
> We also have a bunch of other stuff like element, etc, should it be needed.
> 
> I assume the reason this doesn't work is because those chrome rules _are_ UA
> rules now, right?
> 
> If so, we may be able to store a bit in style rules or rule nodes tells
> whether they came from chrome sheets and use it... Though not sure how
> trivial would that be.
> 
> Dao, did I get that right? (that is, what you're trying to ignore are UA
> rules, they just also happen to be chrome rules).

common.css isn't a UA sheet as far as I know. It's loaded here: https://searchfox.org/mozilla-central/rev/3737701cfab93ccea04c0e9cab211ad10f931d87/browser/components/preferences/in-content/preferences.xul#9

Comment 40

[Emilio Cobos Álvarez (:emilio)]

Attachment: Make appearance an ignored-when-colors-disabled property.

This looks kinda like you were asking for, but this does break other stuff, which may or may not be easy to work around...

We could also tweak IsWidgetStyled to apply to XUL elements when doc colors are disabled...

Comment 41

[Brian Grinstead [:bgrins]]

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=321eb8a45f4b86e7d39eefb57f0f5abb772787ae

Comment 42

[Dão Gottwald [:dao]]

Attachment: Screenshot with Emilio's patch

This shows the glitch Emilio was talking about.

Comment 43

[Ryan VanderMeulen [:RyanVM]]

Would it be possible to get some exploratory testing done on the Try builds in comment 41? Looking in particular for regressions around privileged pages using -moz-appearance (i.e. about: pages). Would be good to confirm that this bug is fixed too.

Comment 44

[Brian Grinstead [:bgrins]]

We did some more debugging and found something unexpected. The color from the UA sheet does get applied, but the background color doesn't unless if we set !important. And AFAICT the background color isn't being overridden by any other UA rules. Emilio, do you have any idea why that might happen?

[0] https://searchfox.org/mozilla-central/rev/40577076a6e7a14d143725d0288353c250ea2b16/toolkit/themes/osx/global/menu.css#131-132

Comment 45

[ovidiu boca[:Ovidiu]]

I tested this issue on Mac OS X 10.12, Windows 10 and Ubuntu 18.04 using the try builds from comment 41 and the issue is still reproducible, but in a different way, depending on OS. 
Here are the results:


On Windows 10 the issue is still reproducible in the same way as described in the first comment. 

On Ubuntu 18.04 in the "Default font" and "Size" dropdowns a square appears, please see the print screen with the actual result https://imgur.com/a/kMDmNfT

On Mac OS X 10.12 the issue is still reproducible, in the "Default font" and "Size" dropdowns a square appears and also if you choose any value from the "Size" this value is not saved. Please see the screen recorder with the issues:
https://streamable.com/3tp72

Comment 46

[Emilio Cobos Álvarez (:emilio)]

background-color is somewhat special:

  https://searchfox.org/mozilla-central/rev/6eea08365e7386a2b81c044e7cc8a3daa51d8754/servo/components/style/properties/properties.mako.rs#3820

Not particularly sure why though.

Comment 47

[Ryan VanderMeulen [:RyanVM]]

Sadly, this has missed Fx61 now.

Comment 48

[:Paolo Amadini]

What is the status of this bug, now that we migrated all the stylesheets from "components.css" to document stylesheets?

Comment 49

[Emilio Cobos Álvarez (:emilio)]

STR look fine for me.

Comment 50

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Agreed, text under cursor now stays visible (black on white), so it's much better. Thank you all!

Ideally, it could be inversed (white on black) so it's easier to know which option is under the cursor. But that could be a separate lower-priority bug.