Closed Bug 1704195 Opened 5 months ago Closed 5 months ago

Hover-state of geolocation prompt is unreadable in dark/alpenglow themes and indistinguishable from unhovered in default theme

Categories

(Firefox :: Theme, defect, P2)

Desktop
Linux
defect

Tracking

()

VERIFIED FIXED
Tracking Status
firefox-esr78 --- unaffected
firefox87 --- unaffected
firefox88 --- unaffected
firefox89 + verified
firefox90 --- verified

People

(Reporter: dholbert, Assigned: dao)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [proton-door-hangers][priority:2a][fixed by bug 1708690])

Attachments

(4 files)

STR:

  1. Visit some site that triggers a geolocation prompt. E.g.: go to https://developer.mozilla.org/en-US/docs/Web/API/Geolocation_API#result and click the demo's Show my location button.

  2. Hover the "Deny"/"Allow" buttons on the popup.

EXPECTED RESULTS:
(A) The hover state should be distinguishable from the unhovered state.
(B) The text should still be readable in the hover state.

ACTUAL RESULTS:
Varying results depending on your Firefox theme:

  • With the "Default" Firefox theme, we violate expectation (A) -- the hover state is only barely distinguishable from the un-hovered state. (I think the text color just has an extremely subtle change.)
  • With the "Dark" and "Alpenglow" Firefox themes, we violate expectation (B) -- the text is unreadable in the hovered state (black text on a dark background)
  • With the "Light" Firefox theme, we live up to both expectations.
Summary: Hover-state of geolocation prompt is unreadable in dark mode, and indistinguishable from unhovered in light mode → Hover-state of geolocation prompt is unreadable in dark/alpenglow themes and indistinguishable from unhovered in default theme
Attachment #9214794 - Attachment description: screenshot with "Alpenglow" theme (I'm hovering the Block button, and it's hard to read → screenshot with "Alpenglow" theme (I'm hovering the Block button, and it's hard to read)

mozregression gives me this regression range:
https://hg.mozilla.org/integration/autoland/rev/44916257e3052502b8d9465b73be4d5a8c4919e7
--> regressed by bug Bug 1703716

(Before that, this popup has its "pre-proton" doorhanger UI, which isn't affected by this usability issue.)

Specifically looks like this would probably be under the umbrella of "browser.proton.doorhangers.enabled" whose value was flipped in that commit.

Regressed by: 1703716

I'm using the latest Linux Nightly, FWIW.

[Tracking Requested - why for this release]: usability regression, with our default theme as well as other themes that we ship with (all but the non-default "light" theme)

Component: General → Theme
Flags: needinfo?(mconley)

Hey dao, are our dark theme fallbacks on Linux not doing what we expect here?

Flags: needinfo?(mconley) → needinfo?(dao+bmo)
OS: Unspecified → Linux
Hardware: Unspecified → Desktop

Set release status flags based on info from the regressing bug 1703716

Priority: -- → P2
Whiteboard: [proton-door-hangers] [priority:2a]

This can be also seen in the Customize page on Ubuntu 18.04 x64, with latest Nightly 89.0a1, while hovering over the Themes list.

Not sure about comment 1. For comment 2 & comment 3, I suspect https://searchfox.org/mozilla-central/source/toolkit/themes/linux/global/button.css#31-42 has too much specificity.

You could try changing button:hover:not(:active,[disabled="true"],[open="true"],[checked="true"],[default="true"]) { to button:where(:hover:not(:active,[disabled="true"],[open="true"],[checked="true"],[default="true"])) { which will reduce the specificity to 0.

Same for the active state. (I suspect the disabled state might be an issue on all platforms too).

Optional cleanup, but macOS could get the same treatment here: https://searchfox.org/mozilla-central/source/toolkit/themes/osx/global/button.css#16,22,28 and then https://searchfox.org/mozilla-central/source/toolkit/themes/shared/popupnotification.inc.css#196,201 could get simplified (no !important on the second declaration, and the first declaration removed).

Molly made a related fix for Windows in https://phabricator.services.mozilla.com/D112103.

Flags: needinfo?(dao+bmo) → needinfo?(mconley)

Thanks for the guidance, ntim!

Flags: needinfo?(mconley)
See Also: → 1706591
See Also: → 1707627

Looks like Dão has explicitly asked for the suggestion from comment #10 in bug 1707627 so that bug should fix this one too, AIUI, so marking a dependency.

Depends on: 1707627

I think bug 1708690 might have fixed this. Daniel, can you confirm?

(In reply to :Gijs (he/him) from comment #12)

Looks like Dão has explicitly asked for the suggestion from comment #10 in bug 1707627 so that bug should fix this one too, AIUI, so marking a dependency.

Bug 1707627 is slightly different, it's about toolbarbutton.css, not button.css.

Depends on: 1708690
No longer depends on: 1707627
Flags: needinfo?(dholbert)

Yup, this is fixed! Default, Dark, and Alpenglow all seem good now (they don't violate expectations as described in comment 0).

mozregression says the fix range is https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=27780a561fa02a7df9f3068f3f1d6dadde083c87&tochange=02c956ff0d2f2c3584939f6d1879dad39795738d

So yes, fixed by bug 1708690. I'll close as FIXED by that bug.

Status: NEW → RESOLVED
Closed: 5 months ago
Flags: needinfo?(dholbert)
Resolution: --- → FIXED
Assignee: nobody → dao+bmo
Whiteboard: [proton-door-hangers] [priority:2a] → [proton-door-hangers][priority:2a][fixed by bug 1708690]
Flags: qe-verify+

I have reproduced this issue using Firefox 89.0a1 (2021.04.09) on Ubuntu 20.04 x64.
I can confirm this issue is fixed, I verified using Firefox 89.0 and Fx 90.0a1 on Ubuntu 20.04 x64, macOS 11.0.1 and Win 8.1.04 x64.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.