1016468 - Want customization options for tab close buttons (back)

Status: VERIFIED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[Alex Shilov]

The browser.tabs.closeButtons pref was removed. It provided an opportunity to place tab-closing button in the end of the tab strip, instead of placing small close button on every tab.

There is no telemetry data based on which you can know how many users used this pref. But for whose it broke some user cases in UX:
1) I have 20 tabs open and want quickly close five of them from the middle. I select first one to delete and click mouse to the static-placed close button right of the tab strip as much times as I want. Each tab width at this moment could stretch and shrink, it doesn't matter as long as the close button stays stock-still. 
Now if tab width are changing when tabs count reducing the close button jumping over tab strip.
2) Then I have 100+ tabs open tab width are 30px, when browser hang (goes unresponsive) I sometimes click two times to change it, now accidentally I could press close button then selecting the tab, it's unacceptable, as user have to reopen tab.
3) If I have 100+ tabs and want to close some specific tabs (based on favicons, like only Google searches tabs), I could move them using Ctrl+Tab by left hand, and by right hand clicking close button in the right. It was easy. Now I can't do that. 

The pref provided a three ways of closing tabs:
0-1: Display close buttons on each tabs
2: Don’t display any close buttons. So user can use keyboard shortcuts (Ctrl-W or Ctrl-F4) or middle click. Note that there was very old bug 78414, so keyboard shortcuts not working if page containing Flash (like youtube player) and it selected. So closing curtain tabs by keyboard is not an option. Middle click is a different UX either. 
3: Display a single close button at the end of the tab strip (Firefox 1.x behavior) 
So I think patch on Bug 865826 can be reverted.

Comment 1

[:Gijs (he/him)]

Bugzilla isn't the place to open a discussion about reverting a change. Please post to firefox-dev instead (which you already have, so I'm not sure why this didn't go there, too).

Comment 2

[Alex Shilov]

The claim "Bugzilla isn't a place for ..." is not an argument, imho.
Bugzilla is for submitting bug, talking about bug and fixing a bug. I can see that behavior in thousands of bugs here. Discussion of the bug should be stayed in the bug comments, and therefor be open and easy to access for average users. 

In the Bug 865826 some dev wanted me not discussing about bug, even if I do it in a constructive way. He point me to open a new bug as regression, so I did.
There was usability regression, and I described in details where is it. If it's Invalid bug, than I don't know what the "bug" meaning is. It's clearly the bug for me.

I'm waiting for any of UX member there, they can tell official UX-team position about this bug, or review bug 865826. 
Developers other from UX-team please not close this bug without argument. I'll try to write to firefox-dev today, but it's hard the average users like me using that list. Lists are usually for the planning.

Comment 3

[Blake Winton (:bwinton) (:☕️)]

Just a thought: Since the discussion is about removing a hidden pref, I don't see it as a UX decision, because it doesn't affect users of supported configurations.  (If the UX team thought it was an important thing to support, it would be in the options.  If you change something behind a screen that says "This might void your warranty!", that's a pretty clear signal that what you're doing isn't officially supported.)

Comment 4

[Justin Dolske [:Dolske]]

This pref dates back to Firefox 2 (bug 308396 and bug 351965). It's a hidden pref that was never exposed in any Firefox UI.

Perhaps bug 865826 could have explained the rationale for the removal more explicitly, but it's pretty clear-cut. As a general rule, we avoid having preferences for things unless we see a strongly compelling reason that it is likely to be used by a significant number of users. Lots of preferences adds code complexity, increases maintenance and testing costs, and hurts our ability to ship a modern browser. This is consistent going back to the original Firefox charter -- http://www-archive.mozilla.org/projects/firefox/charter.html. Addons are the expected delivery vehicle for features and tweaks that we don't believe are relevant to the majority of our user base.

Sometimes we want/need hard data (like Telemetry) to help decide what to do, other times the collective experience/wisdom of a team of engineers and UX experts is more than adequate to make a decision. This is one of those times. (See also: analysis paralysis)

Removing a hidden, never-exposed pref is a no-brainer, and the wins from the patch in bug 865826 are clear. As a Firefox module peer I see no need to revisit this decision.

[Aside: We try to keep Bugzilla focused more on technical implementation, and use other mediums (like email lists) for general discussion/debate. The redirect to firefox-dev was appropriate in that sense, but nor is it a forum for endless debate.]

Comment 5

[the-edmeister]

Quite honestly the "browser.tabs.closeWindowWithLastTab" should have been changed to "false" as part of Bug 865826 - there is definitely a regression in Firefox 31 as far as usability.

Comment 6

[Steve Brecht]

Also strongly agreed that this is a big UI regression for FireFox for users that used it.  The argument it wasn't exposed isn't correct as it was exposed through many plug-ins to thousands of users who then employed the functionality.  I really don't understand how a UI designer doesn't see the advantage of this for heavy tab use clients.

Comment 9

[:Gijs (he/him)]

Going to make the summary more descriptive so it's easier to find in searches.