Closed Bug 1933479 Opened 11 months ago Closed 9 months ago

Add close button on hover to vertical tabs in collapsed state

Categories

(Firefox :: Sidebar, enhancement, P1)

enhancement

Tracking

()

VERIFIED FIXED
136 Branch
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.

Duplicate of this bug: 1928400
Assignee: nobody → kcochrane

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.

Flags: needinfo?(ayeddi)

(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.

Severity: -- → N/A

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.

(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.

(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).

(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.

Flags: needinfo?(ayeddi)
Flags: needinfo?(ayeddi)

I have clarified with Yulia, that the following is still true:

  1. Mute/Unmute buttons - always visible, even on inactive tabs (exists for tabs that are playing audio)
  2. 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.

Flags: needinfo?(ayeddi)
Status: NEW → ASSIGNED
Attachment #9444455 - Attachment description: WIP: Bug 1933479 - WIP add tab close button on hover to vertical tabs when sidebar is collapsed → WIP: Bug 1933479 - Add tab close button on hover to vertical tabs when sidebar is collapsed
Attachment #9444455 - Attachment description: WIP: Bug 1933479 - Add tab close button on hover to vertical tabs when sidebar is collapsed → Bug 1933479 - Add tab close button on hover to vertical tabs when sidebar is collapsed
Depends on: 1939891
Pushed by kcochrane@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ac1633f93f5c Add tab close button on hover to vertical tabs when sidebar is collapsed r=desktop-theme-reviewers,tabbrowser-reviewers,sidebar-reviewers,nsharpley,emilio,dao

Backed out for causing bc failures @ browser_sidebar_collapsed_close_tab_button.js

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
Flags: needinfo?(kcochrane)
Pushed by kcochrane@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4b7b61de1b16 Add tab close button on hover to vertical tabs when sidebar is collapsed r=desktop-theme-reviewers,tabbrowser-reviewers,sidebar-reviewers,nsharpley,emilio,dao

Backed out for causing bc failures @ browser_startup_images.js

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.

Pushed by kcochrane@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3b597e62bd28 Add tab close button on hover to vertical tabs when sidebar is collapsed r=desktop-theme-reviewers,tabbrowser-reviewers,sidebar-reviewers,nsharpley,emilio,dao
Flags: needinfo?(kcochrane)
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 136 Branch
Regressions: 1941177
Regressions: 1941184

Verified as fixed in our latest Nightly 136.0a1 (2025-01-12).

Status: RESOLVED → VERIFIED

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.

(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.

Blocks: 1941344
See Also: → 1941588

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.

See Also: → 1941344
Depends on: 1962696
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: