The Cancel, Copy, and Download buttons have no focus styling when taking a screenshot
Categories
(Firefox :: Screenshots, defect, P2)
Tracking
()
Accessibility Severity | s3 |
People
(Reporter: tgiles, Assigned: niklas)
References
Details
(Whiteboard: )
Attachments
(1 obsolete file)
I don't know if this will block enabling the component on Nightly or not, since I'm not sure if this is a valid case or not; but bugs are cheap.
STR:
- Set
screenshots.browser.component.enabled
to true - Navigate to https://bugzilla.mozilla.org/home (or any webpage)
- Use keyboard shortcut (Ctrl + Shift + S) to take a screenshot
- Select a portion on screen with your mouse to bring up the Cancel, Copy, and Download buttons for this section
Expected:
- If I focus the Cancel, Copy, or Download buttons, I would expect styling similar to the hover state plus a focus outline
Actual:
- No change in visual display when focused, no focus outline appears.
I'm not sure how common this use case is, using both mouse and keyboard to take a screenshot. If we take a screenshot via the save visible/save full page buttons, then the buttons that appear have the correct styles when focused. In other words, I don't know how you would control the mouse pointer via keyboard input...I'm sure there is software to make this happen though. Like if you're controlling the pointer via keyboard, would focus states be a concern then? I'm not sure and I don't have a good answer to that question at the moment...but again, bugs are cheap so might as well have this on file.
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
We should make the border region circles appearance button when we add the rules for hover states
Updated•2 years ago
|
Comment 2•2 years ago
|
||
It appears these buttons get no focus styling, but if you look in the inspector and check the :focus-visible
thing, the buttons (e.g. button#copy
) correctly match the button:focus-visible
rule in common-shared.css:
outline: var(--in-content-focus-outline-width) solid var(--in-content-focus-outline-color);
But it turns out that if you look at the computedStyle there, both --in-content-focus-outline-width
and --in-content-focus-outline-color
appear to have no value. You can confirm this by giving them a value in that rule or the (element)
block for the selected element in the inspector:
--in-content-focus-outline-width: 4px;
--in-content-focus-outline-color: red;
Its kind of a long chain of vars referencing other vars to resolve those to a value, but as far as I can tell, all the needed stylesheets are@imported
and we should have resolved 2px
as the outline-width, and --in-content-focus-outline-color
= --focus-outline-color
= --color-accent-primary
= --brand-color-accent
= --color-blue-50
= #0060df
. However, its a long chain and as the end result indicates, something is not right there.
Comment 3•1 years ago
|
||
:emilio, can you spot why these vars don't resolve their values here? This is the html buttons defined in the <screenshots-buttons>
CE which is inside the anonymous content shadowRoot when you toggle on the (screenshots.browser.component.enabled
) screenshots.
The in-content/common.css
imports common-shared.css
, which imports design-tokens-brand.css
which imports design-tokens-shared.css
where the concrete values for these variables are ultimately defined.
As we're in a weird spot here I'm not sure how much I trust what the devtools inspector is telling me, but it doesnt seem to have values for those --in-content-focus-
variables necessary to draw the focus outline in this context.
Comment 4•1 years ago
|
||
These only apply to the root, not to the :host
: https://searchfox.org/mozilla-central/rev/7042a4a444f040ed87045c216f97cb73ce9410df/toolkit/themes/shared/design-tokens-shared.css#5
Page native anonymous content intentionally doesn't inherit from the root (and those styles aren't applied on the page anyways).
So --focus-outline-width
is not defined causing this. Changing that line to :root, :host
would work (or maybe even better, :root, :host(:-moz-native-anonymous)
for clarity on when it's really needed, and to not make overriding these confusing).
Does that help?
Comment 5•1 years ago
|
||
I don't see to be able to focus those using the keyboard anyways (on Linux) tho...
Assignee | ||
Comment 6•1 years ago
|
||
Hey Emilio, this doesn't seem to be working for me because the structure of the anonymous content is now like the following
<div role="presentation" class="moz-custom-content-container"> // This is the :-moz-native-anonymous
<div role="presentation"></div> // this is a :host
<div role="presentation"></div> // this is a :host
</div>
so the :host(:-moz-native-anonymous)
selector isn't selecting anything.
Comment 7•1 years ago
|
||
The <div role="presentation">
should also match :-moz-native-anonymous
. Does it not?
Comment 8•1 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
I don't see to be able to focus those using the keyboard anyways (on Linux) tho...
That is bug 1820015. One doesn't technically block the other, but fixing this would help when we need to verify bug 1820015 as without the focus outline, its not at all clear if the buttons have focus or not.
Assignee | ||
Comment 9•1 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)
The
<div role="presentation">
should also match:-moz-native-anonymous
. Does it not?
I did some more testing and yes, I can select it with div:-moz-native-anonymous
.
But :host(:-moz-native-anonymous)
doesn't match.
Assignee | ||
Comment 10•1 years ago
|
||
Updated•1 years ago
|
Comment 11•1 year ago
|
||
Fixed by a patch in bug 1850811.
Description
•