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

RESOLVED WORKSFORME

Status

()

defect
P1
normal
RESOLVED WORKSFORME
Last year
10 months ago

People

(Reporter: gerald, Assigned: emilio)

Tracking

({access, regression})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox-esr60 wontfix, firefox59 unaffected, firefox60+ wontfix, firefox61+ wontfix, firefox62 wontfix, firefox63 fixed)

Details

Attachments

(7 attachments, 1 obsolete attachment)

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.)
Hey gerald,

I'm not seeing this on macOS. Are you on Windows?
Flags: needinfo?(gsquelart)
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.
Blocks: 1420229
Flags: needinfo?(gsquelart) → needinfo?(bgrinstead)
Keywords: regression
Priority: -- → P1
(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.
Posted image screenshot on mac
Yeah, seems pretty bad.
Flags: needinfo?(jwalker)
Sorry, meant to type a comment.  Joe, if Brian is busy can you find someone to work on this?
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
Flags: needinfo?(jwalker) → needinfo?(dolske)
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
Flags: needinfo?(bgrinstead)
This is the initial UI when opening the dropdown (before it changes to black text). The computed color style is expanded.
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.
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
(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.
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.
Brian, are you still working on this? We've only got about two weeks left for fixes to land in time for 61.
Flags: needinfo?(bgrinstead)
(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.
Flags: needinfo?(bgrinstead) → needinfo?(jaws)
An example of the UI issues mentioned in the new tab page
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.
Blocks: 1457907
No longer blocks: 1420229
See Also: → 1457907
(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
(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.
Flags: needinfo?(jaws) → needinfo?(bgrinstead)
Keywords: access
> 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.
Flags: needinfo?(dolske)
Assignee: nobody → jaws
Status: NEW → ASSIGNED
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?
Attachment #8981953 - Flags: review?(dao+bmo) → review-
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?
(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.
(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 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.
Attachment #8981953 - Flags: review?(dao+bmo) → review-
(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?
Flags: needinfo?(bgrinstead) → needinfo?(dao+bmo)
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.
(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
Flags: needinfo?(dao+bmo)
(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?
(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.
(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?
(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
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.
Flags: needinfo?(dao+bmo)
(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?
Flags: needinfo?(dao+bmo) → needinfo?(bzbarsky)
I don't actually know the answer offhand for stylo.  Emilio, do you?
Flags: needinfo?(bzbarsky) → needinfo?(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
Flags: needinfo?(emilio)
(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
Flags: needinfo?(emilio)
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...
Flags: needinfo?(emilio)
Attachment #8983744 - Flags: feedback?
Attachment #8983744 - Flags: feedback? → feedback?(dao+bmo)
Attachment #8981953 - Attachment is obsolete: true
Assignee: jaws → emilio
This shows the glitch Emilio was talking about.
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.
Flags: needinfo?(brindusa.tot)
Flags: needinfo?(andrei.vaida)
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
Flags: needinfo?(emilio)
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
Flags: needinfo?(brindusa.tot)
Flags: needinfo?(andrei.vaida)
Blocks: 1470830
What is the status of this bug, now that we migrated all the stylesheets from "components.css" to document stylesheets?
Flags: needinfo?(emilio)
Flags: needinfo?(dao+bmo)
STR look fine for me.
Flags: needinfo?(emilio)
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.
Status: ASSIGNED → RESOLVED
Closed: Last year
Flags: needinfo?(dao+bmo)
Resolution: --- → WORKSFORME
Attachment #8983744 - Flags: feedback?(dao+bmo)
No longer blocks: 1470830
Depends on: 1470830
You need to log in before you can comment on or make changes to this bug.