Closed Bug 1600430 Opened 5 years ago Closed 4 years ago

[NSApp isFullKeyboardAccessEnabled] isn't returning the updated value in content processes

Categories

(Core :: Widget: Cocoa, defect, P2)

Desktop
macOS
defect

Tracking

()

VERIFIED FIXED
92 Branch
Tracking Status
firefox91 --- verified
firefox92 --- verified
firefox93 --- verified

People

(Reporter: enndeakin, Assigned: mstange)

Details

Attachments

(1 file)

Steps:

  1. Open some page with the 'full keyboard access' setting off.
  2. Press Tab to navigate around in the page. It should only focus textboxes/lists.
  3. Change the 'full keyboard access' setting by pressing Ctrl+F7 or changing it in system preferences
  4. Press tab to navigate around

Expected: focusing all elements including links
Actual: focuses only textboxes/lists

The change works ok in the chrome process or chrome pages such as preferences. It also works fine when e10s is disabled.

Debugging shows that the [NSApp isFullKeyboardAccessEnabled] is simply returning the wrong value for content processes.

I thought maybe there was some sandbox-type issue as in the state isn't accessible from unprivileged processes. However, the state updates just fine when a new tab is opened when we call [NSApp isFullKeyboardAccessEnabled] from a content process.

Priority: -- → P2
Severity: normal → S3

This is worth retesting, now that "remote lookandfeel" is enabled (bug 1697607).

I can't tell as bug 1699088 broke this in parent processes as well. I filed 1715786.

Depends on: 1715786

If setting dom.ipc.useNativeEventProcessing.content false solves this, it's pretty much same as bug 1486971, in short without spinning native event loop we can't query some system setting value correctly there.

Assignee: nobody → mstange.moz
Status: NEW → ASSIGNED
No longer depends on: 1715786
Pushed by mstange@themasta.com: https://hg.mozilla.org/integration/autoland/rev/cae765809c08 Observe changes to the full keyboard access system pref. r=emilio
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch

Comment on attachment 9230816 [details]
Bug 1600430 - Observe changes to the full keyboard access system pref. r=emilio

Beta/Release Uplift Approval Request

  • User impact if declined: Needed for https://bugzilla.mozilla.org/show_bug.cgi?id=1715786
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See comment 0
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Simple patch to react to system preferences
  • String changes made/needed: none
Attachment #9230816 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9230816 [details]
Bug 1600430 - Observe changes to the full keyboard access system pref. r=emilio

approved for 91 rc1

Attachment #9230816 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Could someone please specify on what platform was the issue fixed? It seems to me that this is MacOS related, could someone confirm this?

Yeah this is macOS-specific.

On MacBook with Mac OS 11.4, the system setting for full keyboard access is a checkbox named "Use keyboard navigation to move between controls" with info "Press the Tab key to move focus forward and Shift Tab to move focus backward."

I am not sure how this feature should work exactly, so I'll put all testing results here for behavior confirmation:

  • Firefox ESR v78.12.0esr:
    ** full keyboard access = OFF : the focus moves from the Wiki's Search field to the main menu bar and back.
    ** full keyboard access = ON : the focus moves through all the page links one-by-one
    ** a browser restart is required after changing the full keyboard access system setting

  • Firefox Release v90.0.2:
    ** full keyboard access = OFF : the focus moves from the Wiki's Search field to the main menu bar and back.
    ** full keyboard access = ON : the focus moves through all the page links one-by-one
    ** a browser restart is required after changing the full keyboard access system setting

  • Firefox Beta v91.0 RC:
    ** full keyboard access = OFF : the focus moves from the Wiki's Search field to the main menu bar and back.
    ** full keyboard access = ON : the focus moves through all the page links one-by-one
    ** a browser restart is NOT required after changing the full keyboard access system setting

  • Firefox Nightly v92.0a1:
    ** full keyboard access = OFF : the focus moves from the Wiki's Search field to the main menu bar and back.
    ** full keyboard access = ON : the focus moves through all the page links one-by-one
    ** a browser restart is NOT required after changing the full keyboard access system setting

The tests are performed by Tab-ing on https://en.wikipedia.org/wiki/Main_Page.

To conclude, the only difference I'm observing is the fact that the restart is not required after changing the full keyboard access system setting for it to take effect in the case of the Nightly92 and Beta91, but it is required for the Release90 and ESR78.

Markus, can you confirm that this was the intended change? Otherwise, please provide me with clear steps to reproduce.

Flags: needinfo?(mstange.moz)

Yes, you should be able to press Ctrl+F7 to change the tabbing behaviour without restarting Firefox. That was the bug here. I confirmed also that the behaviour is now correct.

Setting bug as verified based on the last 2 comments. Thanks!

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Flags: needinfo?(mstange.moz)
OS: Unspecified → macOS
Hardware: Unspecified → Desktop
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: