[NSApp isFullKeyboardAccessEnabled] isn't returning the updated value in content processes
Categories
(Core :: Widget: Cocoa, defect, P2)
Tracking
()
People
(Reporter: enndeakin, Assigned: mstange)
Details
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
Steps:
- Open some page with the 'full keyboard access' setting off.
- Press Tab to navigate around in the page. It should only focus textboxes/lists.
- Change the 'full keyboard access' setting by pressing Ctrl+F7 or changing it in system preferences
- 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.
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
This is worth retesting, now that "remote lookandfeel" is enabled (bug 1697607).
Reporter | ||
Comment 2•4 years ago
|
||
I can't tell as bug 1699088 broke this in parent processes as well. I filed 1715786.
Comment 3•4 years ago
|
||
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.
Comment 4•4 years ago
|
||
Seems like WebKit observes it like this: https://webkit-search.igalia.com/webkit/rev/9af342433c55e18d14e71e1b5b09dcf4ce98dd77/Source/WebKit/UIProcess/Cocoa/WKFullKeyboardAccessWatcher.mm#92-104
Comment 5•4 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)
Seems like WebKit observes it like this: https://webkit-search.igalia.com/webkit/rev/9af342433c55e18d14e71e1b5b09dcf4ce98dd77/Source/WebKit/UIProcess/Cocoa/WKFullKeyboardAccessWatcher.mm#92-104
Link seems broken. This should work:
https://webkit-search.igalia.com/webkit/rev/eba6a9d63a6b4ef59c490052a0cf637183638d93/Source/WebKit/UIProcess/Cocoa/WKFullKeyboardAccessWatcher.mm#89-101
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
Comment 8•4 years ago
|
||
bugherder |
Comment 9•4 years ago
|
||
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
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Comment on attachment 9230816 [details]
Bug 1600430 - Observe changes to the full keyboard access system pref. r=emilio
approved for 91 rc1
Comment 11•4 years ago
|
||
bugherder uplift |
Updated•4 years ago
|
Comment 12•4 years ago
|
||
Could someone please specify on what platform was the issue fixed? It seems to me that this is MacOS related, could someone confirm this?
Comment 13•4 years ago
|
||
Yeah this is macOS-specific.
Comment 14•4 years ago
|
||
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.
Reporter | ||
Comment 15•4 years ago
|
||
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.
Comment 16•4 years ago
|
||
Setting bug as verified based on the last 2 comments. Thanks!
Description
•