Add close button on hover to vertical tabs in collapsed state
Categories
(Firefox :: Sidebar, enhancement, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox136 | --- | verified |
People
(Reporter: sclements, Assigned: kcochrane)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fidefe-sidebar])
Attachments
(1 file)
Yulia's explored a few different options and what she's landed on in is to have a closed tab button that is shown only on hover and if a tab is selected/active. Since the icon will be in the top left of the tab, it'll mean we need to land the full mute/sound playing changes in the same release, see bug 1921060.
Since the icon will be slightly overlapping the launcher per the spec, we discussed having the background color of the circle for the icon to be the same as the selected tab (which is be toolbar-bgcolor). The fill for the icon should probably be whatever is used for tab text color but it'd be a good idea for whomever is working on this to try this out with our standard firefox themes and a few user created themes to make sure Yulia is happy with how this looks.
Updated•11 months ago
|
Updated•11 months ago
|
Comment 2•10 months ago
|
||
Apologies for the drive by comment here, but my Schrödingers button sense is tingling here. Curious if :ayeddi has taken a look at the spec or has any thoughts/suggestions here.
Comment 3•10 months ago
|
||
(In reply to Hanna Jones [:hjones] from comment #2)
Apologies for the drive by comment here, but my Schrödingers button sense is tingling here. Curious if :ayeddi has taken a look at the spec or has any thoughts/suggestions here.
FWIW, I share this concern, raised it in https://phabricator.services.mozilla.com/D231182#inline-1284726 too. Historically, this is precisely the reason why we have not implemented close buttons that appear on hover in the tab bar.
Updated•10 months ago
|
| Reporter | ||
Comment 4•10 months ago
|
||
My understanding of the "Schrödingers button" is of a feature that is only available on hover, which wouldn't be the case here. It's not meant to replace the pre-existing keyboard shortcut to close a tab or the right-click menu option to close a tab. And muting/unmuting sound also has the same pattern (you can mute/unmute on hover, by keyboard shortcut or by context menu) so its unclear why having a close button on hover is perceived as problematic.
If there's suggestions from Anna on how to handle screen reader usage/keyboard nav due to how its positioned, we can certainly implement that. But this is a clear pain point for users that there isn't a one-click close option, which is more obvious with vertical tabs in the collapsed state since they all essentially look like pinned tabs.
Comment 5•10 months ago
|
||
(In reply to Sarah Clements [:sclements] from comment #4)
My understanding of the "Schrödingers button" is of a feature that is only available on hover, which wouldn't be the case here. It's not meant to replace the pre-existing keyboard shortcut to close a tab or the right-click menu option to close a tab.
Putting aside the definition of Schrödinger's buttons, from my perspective the concern is purely for mouse users, so the existence of the keyboard shortcut and context menu doesn't really help.
And muting/unmuting sound also has the same pattern (you can mute/unmute on hover, by keyboard shortcut or by context menu) so its unclear why having a close button on hover is perceived as problematic.
It's more problematic because it's a destructive action, so accidental clicks would be way more annoying.
| Reporter | ||
Comment 6•10 months ago
•
|
||
(In reply to Dão Gottwald [:dao] from comment #5)
(In reply to Sarah Clements [:sclements] from comment #4)
And muting/unmuting sound also has the same pattern (you can mute/unmute on hover, by keyboard shortcut or by context menu) so its unclear why having a close button on hover is perceived as problematic.
It's more problematic because it's a destructive action, so accidental clicks would be way more annoying.
I hear you, that's a fair concern, which is why the button is positioned slightly over the launcher on the top left. Luckily closing a tab is not truly destructive in a sense of it being gone, but not all users may know how to get it back easily. But I do think product and UX have thought through this.
If we're able to land this early enough in Nightly we'll be able to get some initial feedback on it before it goes into release (also for 135 we're still thinking through different roll out scenarios for sidebar/vertical tabs).
Comment 7•10 months ago
|
||
(In reply to Hanna Jones [:hjones] from comment #2)
Apologies for the drive by comment here, but my Schrödingers button sense is tingling here. Curious if :ayeddi has taken a look at the spec or has any thoughts/suggestions here.
Thank you all for your pings, Hanna and Sarah!
My understanding was that we aim to follow the existing tab behavior (from horizontal tabs) as close as possible: Close button is always visible for the active tab, Mute/Unmute tabs are always visible for all tabs, and these options are included in the context/right click menu for each tab (though keyboard-only users would need to activate the tab to focus it and open the context menu). Plus, with the Proton era active tab indication on non-HCM/regular contrast themes, the always-on-screen Close button does serve as an additional indicator of which tab is, in fact, currently open. I may have missed the Close button's visibility change in the updated specs and this is what I need to clarify.
In general, I think for the vertical tab, showing on-hover Close buttons for inactive tabs (without including them in a focus order still) would be an acceptable approach (while always showing the active tab's Close button) - this is an opt-in behavior where a user have control over the clickable area of the tab column/sidebar, while the horizontal tabs does not provide much of resizing, especially when multiple tabs are opened.
(In reply to Dão Gottwald [:dao] from comment #5)
(In reply to Sarah Clements [:sclements] from comment #4)
My understanding of the "Schrödingers button" is of a feature that is only available on hover, which wouldn't be the case here. It's not meant to replace the pre-existing keyboard shortcut to close a tab or the right-click menu option to close a tab.
Putting aside the definition of Schrödinger's buttons, from my perspective the concern is purely for mouse users, so the existence of the keyboard shortcut and context menu doesn't really help.
And muting/unmuting sound also has the same pattern (you can mute/unmute on hover, by keyboard shortcut or by context menu) so its unclear why having a close button on hover is perceived as problematic.
It's more problematic because it's a destructive action, so accidental clicks would be way more annoying.
I agree that the destructive action needs more attention and more predictability too. And I think that when a clickable area size is a concern for a user, they are more likely to choose a larger form of the vertical tabs (not collapsed one).
Keeping the NI on because I need to clarify some things with the UX.
Updated•10 months ago
|
Comment 8•10 months ago
|
||
I have clarified with Yulia, that the following is still true:
- Mute/Unmute buttons - always visible, even on inactive tabs (exists for tabs that are playing audio)
- Close tab button - is always visible for the active tab, inactive tabs only on hover (exists for all tabs).
Plus, both the Close and Mute/Unmute tab actions are available in the context menu (right-click menu) for each tab, thus this should be an acceptable approach from the accessibility perspective.
| Assignee | ||
Updated•10 months ago
|
| Assignee | ||
Comment 9•10 months ago
|
||
Updated•10 months ago
|
Updated•10 months ago
|
Comment 10•9 months ago
|
||
Comment 11•9 months ago
|
||
Backed out for causing bc failures @ browser_sidebar_collapsed_close_tab_button.js
- Backout link
- Push with failures
- Failure Log
- Failure line:
TEST-UNEXPECTED-FAIL | browser/components/sidebar/tests/browser/browser_sidebar_collapsed_close_tab_button.js | Uncaught exception in test bound test_toggle_collapse_close_button - at chrome://mochitests/content/browser/browser/components/sidebar/tests/browser/browser_sidebar_collapsed_close_tab_button.js:24 - TypeError: SidebarController.setUIState is not a function
Comment 12•9 months ago
|
||
Comment 13•9 months ago
•
|
||
Backed out for causing bc failures @ browser_startup_images.js
- Backout link
- Push with failures
- Failure Log
- Failure line:
TEST-UNEXPECTED-FAIL | browser/base/content/test/performance/browser_startup_images.js | Loaded image chrome://global/skin/icons/close-12.svg should have been shown. -
bc failures @ browser_sidebar_collapsed_close_tab_button.js
Failure log.
Comment 14•9 months ago
|
||
| Assignee | ||
Updated•9 months ago
|
Comment 15•9 months ago
|
||
| bugherder | ||
Comment 16•9 months ago
|
||
Verified as fixed in our latest Nightly 136.0a1 (2025-01-12).
Comment 17•9 months ago
|
||
Do we indend to add an about:config pref to let users disable the close button?
Maybe it's just me but I happen to be clicking the new close button accidentally all the time. I think I've mistakenly closed at least 10 tabs since yesterday.
Comment 18•9 months ago
|
||
(In reply to Selim Şumlu from comment #17)
Do we indend to add an about:config pref to let users disable the close button?
Maybe it's just me but I happen to be clicking the new close button accidentally all the time. I think I've mistakenly closed at least 10 tabs since yesterday.
We had raised this concern before, see comment 3 and below, but the sidebar team wanted to give this a try anyway. I remain highly skeptical. If your experience is at all representative, then I do not think an about:config pref is the right fix, as average users won't find their way there.
Comment 19•9 months ago
|
||
I have the same issues of other with that close button, I am clicking very often the close button instead to just open the tab.
I usually close them with the mouse middle click button or Ctrl+w, a workaround to disable it it will be very handy.
Description
•