Closed Bug 1949415 Opened 6 days ago Closed 2 days ago

[macOS][Voiceover] Additional focus square on the top left of the first color in manage/create tab group panel

Categories

(Firefox :: Tabbed Browser, defect, P3)

Desktop
macOS
defect
Points:
1

Tracking

()

RESOLVED FIXED
137 Branch
Accessibility Severity s4
Tracking Status
firefox136 --- disabled
firefox137 --- fixed

People

(Reporter: csasca, Assigned: dao, NeedInfo)

References

(Blocks 2 open bugs)

Details

(Keywords: access, Whiteboard: [fidefe-tabgrps])

Attachments

(3 files)

Found in

  • Nightly 137.0a1 (2025-02-19)

Affected versions

  • Nightly 137.0a1 (2025-02-19)
  • Beta 136.0b8

Affected platforms

  • macOS

Preconditions

  • Have voiceover active

Steps to reproduce

  1. Access the create/manage tab group panel
  2. Press tab to focus the color choices

Expected result

  • There is one focus over the selected color

Actual result

  • There is an additional fixed focus on the top left of the first color

Regression range

  • Not a regression.
Blocks: 1928439
Points: --- → 1
Keywords: access
Priority: -- → P3
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Component: Disability Access APIs → Tabbed Browser
Product: Core → Firefox

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

Priority: P3 → --
Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a3cd7e3d9382 Move color inputs off-screen. r=dwalker,tabbrowser-reviewers
Status: ASSIGNED → RESOLVED
Closed: 6 days ago
Resolution: --- → FIXED
Target Milestone: --- → 137 Branch
Attached image image.png

Tried verifying the fix on Firefox 137.0a1 (treeherder build - 20250221095438) on macOS 15.3.1 and it seems that the little focus square is still there but outside the browser now. Any idea about it Dao? Thanks!

Flags: needinfo?(dao+bmo)

(In reply to Catalin Sasca, Desktop Test Engineering [:csasca] from comment #5)

Created attachment 9467696 [details]
image.png

Tried verifying the fix on Firefox 137.0a1 (treeherder build - 20250221095438) on macOS 15.3.1 and it seems that the little focus square is still there but outside the browser now. Any idea about it Dao? Thanks!

Good lord! Anna, any ideas for how to prevent this? :/

Status: RESOLVED → REOPENED
Flags: needinfo?(dao+bmo) → needinfo?(ayeddi)
Priority: -- → P3
Resolution: FIXED → ---
Accessibility Severity: --- → s4

If we don't find a proper fix here, would you prefer I backed out https://hg.mozilla.org/mozilla-central/rev/a3cd7e3d9382? Not sure which behavior is worse.

Flags: needinfo?(mreschenberg)

(In reply to Dão Gottwald [:dao] from comment #7)

If we don't find a proper fix here, would you prefer I backed out https://hg.mozilla.org/mozilla-central/rev/a3cd7e3d9382? Not sure which behavior is worse.

Does the functional behaviour differ between the two patches? e.g. does a user still select the swatch with the fx blue outline as they nav through the options even if the VO cursor box is offscreen?

Also, if the window is at the top of the screen, is there any on-screen VO cursor? or does the issue QA highlighted only happen when the window is not aligned to the menu bar?

Flags: needinfo?(mreschenberg)

I think your patch's behaviour is better than the current behvaiour if (when the window is at the top of the screen) no VO cursor is rendered. This way users can depend on the fx blue focus outline instead and not be as confused by a nearby mis-placement of the VO cursor

Ideally though, it'd be nice to fix this. Do you have any more info on what the errant box is caused by?

(In reply to Morgan Reschenberg [:morgan] from comment #9)

I think your patch's behaviour is better than the current behvaiour if (when the window is at the top of the screen) no VO cursor is rendered. This way users can depend on the fx blue focus outline instead and not be as confused by a nearby mis-placement of the VO cursor

Okay, I'll close this again. Catalin, would you mind filing a new bug on the issue you found?

Ideally though, it'd be nice to fix this. Do you have any more info on what the errant box is caused by?

It's caused by our attempt to hide the input element, by moving it out of the window, and then presumably VoiceOver draws the rect. I'm not sure why we'd want this to be outside of the window though, so maybe that's something to fix in Gecko?

Status: REOPENED → RESOLVED
Closed: 6 days ago2 days ago
Flags: needinfo?(csasca)
Resolution: --- → FIXED

Sure thing Dao. Here's the follow up bug.

Flags: needinfo?(csasca)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: