I came here from the intent to prototype (https://groups.google.com/a/mozilla.org/g/dev-platform/c/bguStcPFugQ/m/4as3Y3rVAQAJ). I checked in Firefox Nightly’s settings. There is a checkbox “Use the tab key to move focus between form controls and links”, which was disabled for me. I’m confused. I’ve been tabbing through links and buttons for years in Nightly. What additional functionality do I get if I enable this checkbox?

(In reply to Šime Vidas from comment #15)

I came here from the intent to prototype (https://groups.google.com/a/mozilla.org/g/dev-platform/c/bguStcPFugQ/m/4as3Y3rVAQAJ). I checked in Firefox Nightly’s settings. There is a checkbox “Use the tab key to move focus between form controls and links”, which was disabled for me. I’m confused. I’ve been tabbing through links and buttons for years in Nightly. What additional functionality do I get if I enable this checkbox?

Are you on macOS? Do you have keyboard navigation enabled in System Settings > Keyboard? The Firefox preference defaults to this value when not overridden. I'm not sure why the checkbox would be disabled, I'll have to look into that.

Yes, macOS, but the previous version (Ventura 13.6.1). Yes, I have keyboard navigation enabled in macOS settings. I tested in Firefox and Firefox Nightly. When the “Use the tab key…” checkbox is not checked, keyboard tab focuses form controls but not links. When the checkbox is checked, it focuses links as well. I guess, that’s the intended behavior.

I’m confused why the ckeckbox was not checked in my Firefox. Maybe I accidentally unchecked it.

I don't see why this wouldn't work? I had to change preferencesBindings
so that unchecking the checkbox actually works instead of setting the
pref to zero.

(In reply to Šime Vidas from comment #15)

I came here from the intent to prototype (https://groups.google.com/a/mozilla.org/g/dev-platform/c/bguStcPFugQ/m/4as3Y3rVAQAJ). I checked in Firefox Nightly’s settings. There is a checkbox “Use the tab key to move focus between form controls and links”, which was disabled for me. I’m confused. I’ve been tabbing through links and buttons for years in Nightly. What additional functionality do I get if I enable this checkbox?

The checkbox being disabled right now means "follow the system settings", unless you check it and then uncheck it. It's a bit bizarre, see the description in https://phabricator.services.mozilla.com/D208602 as for why.

So yes, if you have the system setting on, the checkbox is pretty confusing. It should be fixed with this bug.

Backed out for causing for causing mochitest failures in test_tabindex.html

• Backout link
• Push with failures
• Failure Log
• Failure line:

[task 2024-05-03T00:56:27.412Z] 00:56:27     INFO - TEST-PASS | dom/svg/test/test_tabindex.html | The active element tabindex is 3 
[task 2024-05-03T00:56:27.412Z] 00:56:27     INFO - Buffered messages finished
[task 2024-05-03T00:56:27.413Z] 00:56:27     INFO - TEST-UNEXPECTED-FAIL | dom/svg/test/test_tabindex.html | The active element tabindex is 6 - got 4, expected 6
[task 2024-05-03T00:56:27.413Z] 00:56:27     INFO -     SimpleTest.is@SimpleTest/SimpleTest.js:509:14
[task 2024-05-03T00:56:27.413Z] 00:56:27     INFO -     main@dom/svg/test/test_tabindex.html?currentTestURL=dom%2Fsvg%2Ftest%2Ftest_tabindex.html&closeWhenDone=1&showTestReport=false&expected=pass:79:9
[task 2024-05-03T00:56:27.413Z] 00:56:27     INFO -     SimpleTest.waitForFocus/<@SimpleTest/SimpleTest.js:1058:13
[task 2024-05-03T00:56:27.413Z] 00:56:27     INFO - Not taking screenshot here: see the one that was previously logged
[task 2024-05-03T00:56:27.414Z] 00:56:27     INFO - TEST-UNEXPECTED-FAIL | dom/svg/test/test_tabindex.html | The active element tabindex is 7 - got 5, expected 7
[task 2024-05-03T00:56:27.414Z] 00:56:27     INFO -     SimpleTest.is@SimpleTest/SimpleTest.js:509:14
[task 2024-05-03T00:56:27.414Z] 00:56:27     INFO -     main@dom/svg/test/test_tabindex.html?currentTestURL=dom%2Fsvg%2Ftest%2Ftest_tabindex.html&closeWhenDone=1&showTestReport=false&expected=pass:87:9
[task 2024-05-03T00:56:27.414Z] 00:56:27     INFO -     SimpleTest.waitForFocus/<@SimpleTest/SimpleTest.js:1058:13
[task 2024-05-03T00:56:27.414Z] 00:56:27     INFO - GECKO(1595) | MEMORY STAT | vsize 6688MB | residentFast 89MB | heapAllocated 8MB
[task 2024-05-03T00:56:27.415Z] 00:56:27     INFO - TEST-OK | dom/svg/test/test_tabindex.html | took 71ms
[task 2024-05-03T00:56:27.415Z] 00:56:27     INFO - TEST-START | dom/svg/test/test_tearoff_with_cc.html

https://hg.mozilla.org/mozilla-central/rev/a0417fcb915e
https://hg.mozilla.org/mozilla-central/rev/e82e34aece59

https://hg.mozilla.org/mozilla-central/rev/a546ec29a801

This bug has multiple duplicates, is that a change that should be mentioned in our release notes? Thanks

Release Note Request (optional, but appreciated)
[Why is this notable]: Changed default tab navigation behavior for macOS users.
[Affects Firefox for Android]: no
[Suggested wording]: Links and other focusable elements are now tab-navigable by default on macOS, instead of following macOS' "Keyboard navigation" setting. This is a more accessible default and matches the default in all other platforms. A checkbox in the settings page still allows users to restore the old behavior.
[Links (documentation, blog post, etc)]: this bug is probably enough.

I agree that the focus-difference-for-XUL thing is weird given we're switching to HTML more and more. Perhaps we can have a follow-up to make that distinction reflect purely whether we're on system principal or privileged about, instead of caring about the node namespace?

What should happen is that the focus behaviour shouldn't be dependent on the flavour of element. It should instead be based on the function of the element, so that textfields, dropdowns and so forth are treated consistently. That said, if we insist of having a separate checkbox in our preferences to handle web page behaviour differently, we should base it on that as well. But that seems confusing to me as to which of the many about pages (preferences, newtab, etc) should be treated as which style.

I trying to understand what this patch is doing though, but it's hard to tell exactly as our Mac tab navigation behaviour seems broken yet again.

From reading the patch and checkin comment, it appears to make tab navigation worse. It seems to remove support for the full keyboard access setting and force you to use some other UI to change this. In addition, the Ctrl+F7 keyboard shortcut can no longer be used to switch full keyboard access off and on, meaning I have to choose either to suffer the tab navigation model other platforms use, or one where I cannot focus all items when I need to, I can't toggle it quickly or use the Option key method as Safari does. (I realize of course that accessibility users would need to navigate between all elements).

But maybe I misinterpreted the intent here?

I would recommend closing this bug as wontfix and implementing a behaviour closer to what Safari has done where Tab can be used to cycle between textboxes and lists (and possibly some other things) and Option+Tab can be used to cycle between all elements. Personally, I would remove the special preference UI and just have that the behaviour for all content and chrome UI and the full keyboard access setting can be used to flip the Tab and Option+Tab behaviour around.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #31)

[Suggested wording]: Links and other focusable elements are now tab-navigable by default on macOS, instead of following macOS' "Keyboard navigation" setting. This is a more accessible default and matches the default in all other platforms. A checkbox in the settings page still allows users to restore the old behavior.
[Links (documentation, blog post, etc)]: this bug is probably enough.

Thanks, note added to https://www.mozilla.org/en-US/firefox/127.0a1/releasenotes/