Make preferences auto-focus more reliable

Merge Info

Related Issues

• #42167 (closed)

Backporting

Timeline

• Immediate: patchset needed as soon as possible
• Next Minor Stable Release: patchset that needs to be verified in nightly before backport
• Eventually: patchset that needs to be verified in alpha before backport
• No Backport (preferred): patchset for the next major stable

(Optional) Justification

• Emergency security update: patchset fixes CVEs, 0-days, etc
• Censorship event: patchset enables censorship circumvention
• Critical bug-fix: patchset fixes a bug in core-functionality
• Consistency: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc
• Sponsor required: patchset required for sponsor
• Other: please explain

Merging

• Merge to tor-browser - !fixups to tor-browser-specific commits, new features, security backports
• Merge to base-browser - !fixups to base-browser-specific commits, new features to be shared with mullvad-browser, and security backports
  • NOTE: if your changeset includes patches to both base-browser and tor-browser please clearly label in the change description which commits should be cherry-picked to base-browser after merging

Issue Tracking

• Link resolved issues with appropriate Release Prep issue for changelog generation

Review

Request Reviewer

• Request review from an applications developer depending on modified system:
  • NOTE: if the MR modifies multiple areas, please /cc all the relevant reviewers (since gitlab only allows 1 reviewer)
  • accessibility : henry
  • android : clairehurst, dan
  • build system : boklm
  • extensions : ma1
  • firefox internals (XUL/JS/XPCOM) : ma1
  • fonts : pierov
  • frontend (implementation) : henry
  • frontend (review) : donuts, richard
  • localization : henry, pierov
  • macos : clairehurst, dan
  • nightly builds : boklm
  • rebases/release-prep : dan, ma1, pierov, richard
  • security : ma1
  • signing : boklm, richard
  • updater : pierov
  • misc/other : pierov, richard

Change Description

Instead of waiting until the next loop to focus the sub-category, we wait until the document "load" event if it has not yet fired. This should be more reliable for ensuring the element can be made focusable. Moreover, we can ensure that this fires after the searchInput is focused.

How Tested

With a screen reader active, open the Security Level panel and select "Settings...". Either with the settings tab already open, or with no settings tab. Screen reader should hopefully read out the "Security Level" grouping/panel, with the focus at the "Security Level" heading.

NOTE: With Orca, if the settings panel is already open, then the tab switch will not cause any announcement. But using the "where am I" command (Orca Modifier + Enter) should read back "Security Level".

Without using a screen reader, you can tell where the focus is by pressing Tab or Shift+Tab, and the focus should move to the focusable elements either side of the Security Level heading.

Change was most obvious when testing with NVDA on my windows virtual machine (by modifying the omni.ja). Before this change, sometimes the screen reader's focus would be at the start of the page rather than at the start of the "Security Level" grouping. After this change, I maybe got it once or twice when testing, but then couldn't reproduce it again in the end. I'll give it a more thorough test again in the future, but for now this is an improvement.