(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 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 would work. 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.
Bug 1754097 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(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 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 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.
(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 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.
(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.