1754097 - Pressing `Tab` on main window cycles the close buttons of *all* open tabs

Status: VERIFIED FIXED

(Thunderbird :: Toolbars and Tabs, defect, P4)

Description

[Thomas D. (:thomas8)]

+++ This bug was initially created as a clone of Bug #1754094 +++

Seen on 98.0a1 (2022-02-07) (64-bit)

STR/Actual

With focus on a tab title, pressing tab will now cycle the tab's close button and then all other close buttons of all open tabs. Cycling a potentially randomly large number of elements is usually a bad idea, because it can make general navigation really hard. It's also not even helpful for closing multiple tabs via keyboard (try it!). Somewhere between TB 91 and Daily, this has regressed. Well, switching tabs via arrow keys was broken in TB 91, too.

Expected:

Firefox 96.0.3 (64-bit) has the correct and useful behaviour:

• Shift+Tab into tab title, which will have a clear solid blue focus ring (not the almost invisible thin dotted line which TB is showing)
• Cursor right/left switches to other tabs
• Tab follows the tab cycle of the current tab only

As a sidenote, if we'd allow Del on a focused tab title to close the tab, that might be more efficient than the currently available keyboard methods of closing the tab...

Comment 1

[Henry Wilkes (they/them) [:henry-x]]

This is because the close button is an actual <button> now, rather than <image> https://hg.mozilla.org/comm-central/rev/c6695c5b5708#l4.48

We should probably make the button non-focusable and allow "Delete" to do the same, which follows https://www.w3.org/TR/wai-aria-practices/#keyboard-interaction-21

We should have the Right-Left controls, but I don't think we should auto-open the tab when doing so like firefox because our tab switches are currently disruptive (e.g. reloads messages). We could wait for an explicit "Space" or "Enter" instead.

We would also need to make sure tabs are scrolled into view if the arrowscrollbox overflows.

Maybe we could add controls to re-order tabs. I think you can only do so with drag and drop right now.

Comment 2

[Alessandro Castellani [:aleca]]

(In reply to Henry Wilkes [:henry] from comment #1)

We should probably make the button non-focusable and allow "Delete" to do the same, which follows https://www.w3.org/TR/wai-aria-practices/#keyboard-interaction-21

Yes, I agree.

We should have the Right-Left controls, but I don't think we should auto-open the tab when doing so like firefox because our tab switches are currently disruptive (e.g. reloads messages). We could wait for an explicit "Space" or "Enter" instead.

We're inheriting this feature from firefox as if you focus on a tab and press left/right arrows, you get this error message: JavaScript error: chrome://global/content/elements/tabbox.js, line 372: TypeError: can't access property "advanceSelectedTab", this.container is undefined
Which comes from here: https://searchfox.org/mozilla-central/rev/2a0b0ababd4541ecffb74cbe0820a9d0a25da636/toolkit/content/widgets/tabbox.js#757

We would also need to make sure tabs are scrolled into view if the arrowscrollbox overflows.

Indeed.

Maybe we could add controls to re-order tabs. I think you can only do so with drag and drop right now.

This could be useful, maybe through a CTRL+arrow keyboard action.

Comment 3

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani [:aleca] from comment #2)

(In reply to Henry Wilkes [:henry] from comment #1)

We should probably make the button non-focusable and allow "Delete" to do the same, which follows https://www.w3.org/TR/wai-aria-practices/#keyboard-interaction-21

Yes, I agree.

Yes, yes, yes! I just love how Henry knows the specs, and the specs are great, too!

We should have the Right-Left controls, but I don't think we should auto-open the tab when doing so like firefox because our tab switches are currently disruptive (e.g. reloads messages). We could wait for an explicit "Space" or "Enter" instead.

That would be a bit confusing and delaying. I think we could accept a little bit of disruption due to the current design (like a message reloading and losing scroll position), and implement the keyboard tab change correctly as we'll want it when tabs will behave correctly in the near future ("real" tab per message is already being worked on by Geoff, isn't it?).

We're inheriting this feature from firefox as if you focus on a tab and press left/right arrows, you get this error message: JavaScript error: chrome://global/content/elements/tabbox.js, line 372: TypeError: can't access property "advanceSelectedTab", this.container is undefined
Which comes from here: https://searchfox.org/mozilla-central/rev/2a0b0ababd4541ecffb74cbe0820a9d0a25da636/toolkit/content/widgets/tabbox.js#757

We would also need to make sure tabs are scrolled into view if the arrowscrollbox overflows.

Indeed.

This works in FF 96.0.3 (64-bit), can we port something?

Maybe we could add controls to re-order tabs. I think you can only do so with drag and drop right now.

This could be useful, maybe through a CTRL+arrow keyboard action.

Useful indeed, but Ctrl+arrow is taken for moving focus to another tab while preserving currently selected Tabs. In Firefox, you can then press Space (still with Ctrl) on several non-adjacent tabs to select them and act on selected tabs (move, close etc.). Nifty! Try it in FF!

I think Alt+Arrow would work (also consistent with shortcut for reordering attachments in composition). Ideally, and more intricate, this would support multiple selected tabs, too, and they may not be adjacent as mentioned. Similar to what I did for reordering non-adjacent selected attachments in composition's attachment pane, you'd have to group the selected tabs together first (towards the last/first selected tab according to the desired direction, right/left) before you start moving them as a group.

Comment 4

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1754097 - Make the close tab button non-focusable. r=aleca

Comment 5

[Henry Wilkes (they/them) [:henry-x]]

I'm just adding a small patch for 102 to close off the extra tab stops. We'll implement arrow key controls later (hence the "leave-open" keyword).

Comment 6

[Magnus Melin [:mkmelin]]

This seems to have landed already (all code is already there).

Comment 7

[Magnus Melin [:mkmelin]]

Ah, ignore me...

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/deb7fbdd0722
Make the close tab button non-focusable. r=aleca

Comment 10

[Thomas D. (:thomas8)]

(In reply to Henry Wilkes (they/them) [:henry] from comment #5)

I'm just adding a small patch for 102 to close off the extra tab stops. We'll implement arrow key controls later (hence the "leave-open" keyword).

Thank you Henry for fixing the main problem of this bug and for your valuable insights and energetic plans. Let's close this for clarity of bug management. I've moved all the rest to Bug 1782348 for a clean start, and found that we could actually port some of the existing Firefox behaviour.

Comment 11

[Thomas D. (:thomas8)]

Verified fixed on 102.1.0 (64-bit), Win10.