Reader view doorhanger uses 'active' colour for focused dropdown buttons; should match hover colour instead
Categories
(Toolkit :: Reader Mode, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox78 | --- | fixed |
People
(Reporter: yoasif, Unassigned)
References
Details
(Keywords: nightly-community)
Attachments
(2 files)
Steps to reproduce:
- Go to https://getpocket.com/explore/item/who-still-buys-wite-out-and-why
- Enable reader view
- click any of increase/decrease font size, increase/decrease content width, and increase/decrease line height
What happens:
The active focus color gets stuck to the button as I hover over other buttons.
Expected result:
The active color should only be active momentarily.
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Hi akshitha! Any chance you might have some time to look at this?
Comment 2•4 years ago
|
||
FWIW, I cannot reproduce this on macOS or Windows. Are you seeing this on Linux?
Reporter | ||
Comment 3•4 years ago
|
||
Yes, it is happening in Linux, and in all color modes - I hadn't noticed previously because it is less obvious.
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 4•4 years ago
|
||
(In reply to Asif Youssuff from comment #3)
Yes, it is happening in Linux, and in all color modes - I hadn't noticed previously because it is less obvious.
So I just managed to repro on Windows - but only after using keyboard focus to move around the document. If I close it and open the same article another time, and don't use the [tab] key, the problem goes away again. The styling is wrong, and should match :hover, not :active styling.
However, I also think the distinction between Linux and Windows is wrong here. Emilio, why does :-moz-focusring
apply on Linux when the keyboard has not been used to navigate the document?
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Talked on matrix with Emilio. Filed bug 1638127 for the Linux focus behaviour.
Comment 6•4 years ago
|
||
Sigh, bugzilla, at no point did I mark this fixed.
Comment 7•4 years ago
|
||
Though I am not really sure whether there's any value in keeping both this and bug 1637847 open, they feel pretty interrelated.
Comment 8•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #7)
Though I am not really sure whether there's any value in keeping both this and bug 1637847 open, they feel pretty interrelated.
Hm, though I think this bug might be fixed as a result of the design changes in bug 1637652, and bug 1637847 isn't fixed yet. Need to doublecheck.
Comment 9•4 years ago
|
||
I can still reproduce on Nightly build 20200523092124 if one of the buttons gets focus.
Comment 10•4 years ago
|
||
This is a regression from bug 1550836. It doesn't reproduce on Firefox 77.
https://hg.mozilla.org/mozilla-central/rev/1281f97e9ddd#l9.571 added focusring selectors to the CSS that changes the button color. Now, buttons get the hover color both when they hovered and when they are focused. Before, they only got the color when they were hovered.
Comment 11•4 years ago
|
||
(In reply to Mathew Hodson from comment #9)
Created attachment 9151285 [details]
Screenshot of menu showing the background color changed for two buttonsI can still reproduce on Nightly build 20200523092124 if one of the buttons gets focus.
Sorry, but I think I'm looking at this screenshot differently. Using active styling (ie the same as when you've got a mousebutton down on top of a button) for focus would be incorrect, but your screenshot shows hover styling. So this bug as filed is fixed - in dark mode you wouldn't get the white styling shown in the screenshot from comment #0. (I also tested locally on macOS to confirm.)
Using the same styling for hover and focus was sort of intentional - if you're using keyboard focus, having a nicer visual focus indicator than the default one is a feature, not a bug. Of course, having it be the same as the hover styling can be confusing, and we could morph this bug a second time and make it about that... but that doesn't seem hugely important to me, especially now that bug 1638127 is fixed, so (even on Linux...) you'll only see the focus styling if you're deliberately using keyboard focus to engage with the buttons and dropdown, in which case you're probably less likely to use the mouse at the same time anyway.
Matthew, am I missing something here?
Comment 12•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #11)
"Mathew Hodson" != "Matthew Hodgson" ;)
Comment 13•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #11)
Sorry, but I think I'm looking at this screenshot differently. Using active styling (ie the same as when you've got a mousebutton down on top of a button) for focus would be incorrect, but your screenshot shows hover styling. So this bug as filed is fixed - in dark mode you wouldn't get the white styling shown in the screenshot from comment #0. (I also tested locally on macOS to confirm.)
Using the same styling for hover and focus was sort of intentional
You're right I missed the distinction between active color and hover color.
If focus showing the hover color is intentional, then this was fixed by bug 1637993. That's when the new behavior shows up.
Comment 14•4 years ago
|
||
(In reply to Matthew Hodgson from comment #12)
(In reply to :Gijs (he/him) from comment #11)
"Mathew Hodson" != "Matthew Hodgson" ;)
I am mortified. Sorry to both of you!
(In reply to Mathew Hodson from comment #13)
If focus showing the hover color is intentional, then this was fixed by bug 1637993. That's when the new behavior shows up.
Alright. Let's close this bug out, and I've filed bug 1640505 about distinguishing focus/hover styling in these dropdowns.
Updated•4 years ago
|
Updated•4 years ago
|
Description
•