Closed Bug 1799547 Opened 2 years ago Closed 1 year ago

The Cancel, Copy, and Download buttons have no focus styling when taking a screenshot

Categories

(Firefox :: Screenshots, defect, P2)

defect

Tracking

()

RESOLVED WORKSFORME
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:

  1. Set screenshots.browser.component.enabled to true
  2. Navigate to https://bugzilla.mozilla.org/home (or any webpage)
  3. Use keyboard shortcut (Ctrl + Shift + S) to take a screenshot
  4. 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.

Severity: -- → S3
Priority: -- → P2
Whiteboard: [access-s3]

We should make the border region circles appearance button when we add the rules for hover states

Accessibility Severity: --- → s3
Whiteboard: [access-s3] →

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.

: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.

Flags: needinfo?(emilio)

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?

Flags: needinfo?(emilio)

I don't see to be able to focus those using the keyboard anyways (on Linux) tho...

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.

Assignee: nobody → nbaumgardner
Status: NEW → ASSIGNED

The <div role="presentation"> should also match :-moz-native-anonymous. Does it not?

(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.

(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.

See Also: → 1850811
Attachment #9350655 - Attachment is obsolete: true

Fixed by a patch in bug 1850811.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: