865826 - Remove the browser.tabs.closeButtons pref

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

The browser.tabs.closeButtons pref is only discoverable via about:config. It provides other locations for the tab close buttons, but none that we plan to move towards in the future.

These would be better supported and more discoverable if they were implemented by an add-on.

0: Display a close button on the active tab only
1: Display close buttons on all tabs (Default)
2: Don’t display any close buttons
3: Display a single close button at the end of the tab strip (Firefox 1.x behavior) 

Because we are removing this pref, we will effectively be migrating users back to the default value of 1.

To fix this bug, you'll need to update the following places:
http://mxr.mozilla.org/mozilla-central/search?string=browser.tabs.closeButtons
http://mxr.mozilla.org/mozilla-central/search?string=mCloseButtons

and remove mentions of the pref in:
http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js

Comment 1

[James Lanham]

I've looked it over, and am interested in working on this as my first bug. Any objections?

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Nope, go for it! :)

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

James, any progress on this?

Comment 4

[James Lanham]

I'm sorry, I've switched computers and haven't downloaded any dev stuff onto here yet. I would appreciate if someone else would take over, it might take me a while because I have a lot on my plate right now.

Comment 5

[Yati Sagade]

I'd like to work on this. Can someone please assign this to me?

Comment 6

[Yati Sagade]

Sorry, did not notice you were assigned :)

Comment 7

[Dão Gottwald [:dao]]

Attachment: patch

Comment 8

[Dão Gottwald [:dao]]

Attachment: patch

Comment 9

[Dão Gottwald [:dao]]

Attachment: patch

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8409012 [details] [diff] [review]
patch

Review of attachment 8409012 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/modules/BrowserUITelemetry.jsm
@@ -61,5 @@
>      "TabsToolbar": [
>        "tabbrowser-tabs",
>        "new-tab-button",
>        "alltabs-button",
> -      "tabs-closebutton",

Is this going to affect UITelemetry numbers that are counting how many items users have in their TabsToolbar? I'll flag :mconley about this.

Comment 11

[Jared Wein [:jaws] (please needinfo? me)]

Mike, please see the question above in comment #10.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #10)
> Comment on attachment 8409012 [details] [diff] [review]
> patch
> 
> Review of attachment 8409012 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/modules/BrowserUITelemetry.jsm
> @@ -61,5 @@
> >      "TabsToolbar": [
> >        "tabbrowser-tabs",
> >        "new-tab-button",
> >        "alltabs-button",
> > -      "tabs-closebutton",
> 
> Is this going to affect UITelemetry numbers that are counting how many items
> users have in their TabsToolbar? I'll flag :mconley about this.

No, this should be fine. We don't do raw counting of toolbar contents - we just see what built-in items were added, moved, removed, or stayed put. This patch just removes tabs-closebutton from the list of built-in items, which is fine.

Comment 13

[Dão Gottwald [:dao]]

https://hg.mozilla.org/integration/fx-team/rev/1c2ef0d3d997

Comment 14

[Carsten Book [:Tomcat]]

sorry had to backout for test failures like https://tbpl.mozilla.org/php/getParsedLog.php?id=38478621&tree=Fx-Team

Comment 15

[Dão Gottwald [:dao]]

https://hg.mozilla.org/integration/fx-team/rev/1f5f1fe135b9

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1f5f1fe135b9

Comment 17

[WildcatRay]

I would like to point out that this patch has led to the breaking of addons that utilized this pref and/or the code that supports it. In my case, I use Tab Mix Plus. Others users have reported that with TMP enabled, the browser is not usable.

I am disappointed that after this was proposed, no one asked if this change would negatively impact addons and, if it did negatively impact addon, should the change be implemented?

Honestly, "discover-ability" is quite low on the scale of things that need to be fixed, especially when addons already exist that utilize this pref and/or its code.

I hope you will reconsider this patch given the negative impact it is causing addons.

Comment 18

[Dão Gottwald [:dao]]

(In reply to [e-mail] from comment #17)
> I would like to point out that this patch has led to the breaking of addons
> that utilized this pref and/or the code that supports it. In my case, I use
> Tab Mix Plus. Others users have reported that with TMP enabled, the browser
> is not usable.

This is not surprising at all. Due to its tight integration with tabbrowser, it breaks very easily when we touch tabbrowser. Usually it's updated quite quickly.

Comment 19

[WildcatRay]

(In reply to Dão Gottwald [:dao] from comment #18)
> (In reply to [e-mail] from comment #17)
> > I would like to point out that this patch has led to the breaking of addons
> > that utilized this pref and/or the code that supports it. In my case, I use
> > Tab Mix Plus. Others users have reported that with TMP enabled, the browser
> > is not usable.
> 
> This is not surprising at all. Due to its tight integration with tabbrowser,
> it breaks very easily when we touch tabbrowser. Usually it's updated quite
> quickly.

Dao,

This is not about breaking Tab Mix Plus. It is about making a change that does little if anything to improve the browser or correct a problem with the browser, but does negatively affect addons. In other words, there was no risk analysis conducted to determine what the effects of this change would be and if those effects should or should not be avoided.

Comment 20

[Dão Gottwald [:dao]]

You made a general claim about add-on compatibility and used TMP as an example, to which I responded. You can't extrapoate from TMP to other add-ons. While we made no formal risk analysis, we can say that, based on our experience with former changes to tabbrowser, this patch is unlikely to break lots of add-ons.

Comment 21

[Luís Miguel [:quicksaver] (not reading bugmail)]

(In reply to Dão Gottwald [:dao] from comment #20)
> While we made no formal risk analysis, we can say that, based on
> our experience with former changes to tabbrowser, this patch is unlikely to
> break lots of add-ons.

FYI, it broke my OmniSidebar, although that'll be easy to fix on my side. ;)

PS. Please see bug 1001871, although not critical for the functioning of the browser, I think it's still important.

Comment 22

[Dão Gottwald [:dao]]

(In reply to Luís Miguel [:Quicksaver] from comment #21)
> FYI, it broke my OmniSidebar, although that'll be easy to fix on my side. ;)

Due to the removal of the tabs-closebutton class, I suppose? It's unfortunate that we set the precedent of using that class outside of tabbrowser and then add-ons followed us. They should be using the close-icon class instead. I'm adding the addon-compat keyword for this.

Comment 23

[Luís Miguel [:quicksaver] (not reading bugmail)]

(In reply to Dão Gottwald [:dao] from comment #22)
> (In reply to Luís Miguel [:Quicksaver] from comment #21)
> > FYI, it broke my OmniSidebar, although that'll be easy to fix on my side. ;)
> 
> Due to the removal of the tabs-closebutton class, I suppose?

Yep, that was it, I was getting the close button DOM node through a querySelectorAll('toolbarbutton.tabs-closebutton') in the header. It's an easy change to make in the add-on of course, but I thought you would want to know.

Comment 24

[[github robot]]

Commit pushed to master at https://github.com/mozilla/addon-sdk

https://github.com/mozilla/addon-sdk/commit/b95c9d3ec4a49ca8a557e0126c4663c5c01f2b08
Bug 865826 - Remove the browser.tabs.closeButtons pref. r=jaws

Comment 25

[PimpUigi]

Seriously now...WTF
I've been using option 3 since Firefox 1, and having this "only in about:config" is absolutely no **** reason to remove this from the browser.

God damnit! wtf is wrong with you idiots?!
*Stop* removing good things from the browser.

No more padding on the buttons in small buttons mode in Fx8
No more small buttons at all in Fx29
No more add ons bar in Fx29
No more throbber in Fx29
No more help button in the app menu, you have to press alt to show the menu...
And now no more close tabs button options, so I can't set something up that doesn't require me to move the mouse all over the damn screen??

No! I have to spend *hours* (per removed thing, this turns into days, which turns into weeks, my whole **** month has been about fixing all this **** for Fx29) installing, learning, and configuring and changing css code and js code for add ons that slow my browser down?!

You **** jackasses. Cut it the **** out. All that **** above does is turn people into ChromeTARDS.
I go all over the damn place promoting your browser, *I* shouldn't have to put out my own damn edition of it to fix the **** you break.

God forgive me for ranting and saying these things. : (

Comment 26

[Matthew N. [:MattN]]

(In reply to PimpUigi from comment #25)
> No more help button in the app menu, you have to press alt to show the
> menu...

It is in the app menu, it's the question mark icon in the footer which is standard for "help".

Comment 27

[PimpUigi]

Yeah, you're right. Haha.

Comment 28

[Octoploid]

(In reply to PimpUigi from comment #25)
> Seriously now...WTF
> I've been using option 3 since Firefox 1, and having this "only in
> about:config" is absolutely no **** reason to remove this from the browser.

+1

What is going on at Mozilla? Is there no management in place anymore? 
Can every random developer remove APIs that have been supported for years?

Please revert this commit ASAP. 
Thanks.

Comment 29

[Michael Loney]

Please provide some way to add this back ASAP. Firefox now feels dumbed down just like Chrome. Why would anyone remove this without providing at least an addon to add the functionality back first? Now I have more wasted space on my tabs. I have tweaked this preference on ever Firefox install on Linux and Windows for years. Since I use a mouse with a middle button, I have no purpose for the close button. I can tolerate and even enjoy australis but this is going too far.

Comment 30

[Aris]

I will add the close tab button options to CTR add-on.

Comment 31

[Fyren]

Seems like adding .tab-close-button { display: none !important; } to userChrome.css is enough to make it act like removed pref when it had a value of 2.

Comment 32

[Dirkjan Ochtman (:djc)]

I've built a small addon that takes care of removing the close buttons:

https://addons.mozilla.org/en-US/firefox/addon/no-close-buttons/

Comment 33

[Aris]

Latest CTR beta restores the three missing states from browser.tabs.closeButtons preference,
--> Fx31 --> CTR prefwindow --> tab close settings on main tab

https://addons.mozilla.org/addon/classicthemerestorer/versions/1.1.9beta17

Comment 34

[Dão Gottwald [:dao]]

It may make sense to have the release notes link to the add-on in comment 32 for removing all tab close buttons and/or comment 33 for completely restoring the pref.

Comment 35

[Tim Nguyen :ntim]

(In reply to Dão Gottwald [:dao] from comment #34)
> It may make sense to have the release notes link to the add-on in comment 32
> for removing all tab close buttons and/or comment 33 for completely
> restoring the pref.

I would say comment 33 since it has all the previously included options.

Comment 36

[Sylvestre Ledru [:Sylvestre]]

dao, could you propose some wordings for the release notes? Thanks
By the way, you confirm that it is going to be for 31?

Comment 37

[Dão Gottwald [:dao]]

(In reply to Sylvestre Ledru [:sylvestre] from comment #36)
> dao, could you propose some wordings for the release notes? Thanks

"The browser.tabs.closeButtons hidden preference is no longer supported. Add-ons can be used to customize the tab close buttons (link 1 <https://addons.mozilla.org/firefox/addon/no-close-buttons/>, link 2 <https://addons.mozilla.org/firefox/addon/classicthemerestorer/>)."

> By the way, you confirm that it is going to be for 31?

Yes.

Comment 38

[:Gavin Sharp [email: [e-mail]]]

(In reply to Dirkjan Ochtman (:djc) from comment #32)
> I've built a small addon that takes care of removing the close buttons:
> 
> https://addons.mozilla.org/en-US/firefox/addon/no-close-buttons/

Thanks Dirkjan!

Comment 39

[tyaremco]

Sorry, where is the explanation for this bug?  You know, what are the reasons for it to exist?

> The browser.tabs.closeButtons pref is only discoverable via about:config. 

Yes, so are many prefs.  Why is this is even mentioned?

> It provides other locations for the tab close buttons

It provides ONE other location: the end of the tabbar.

> but none that we plan to move towards in the future.

So, modify the pref?  Why not?

> These would be better supported and more discoverable if they were implemented by an add-on.

How could a feature already baked into Firefox be better supported by an entity other than Mozilla?  

Wouldn't it also be more discoverable if it was say, put into an options dialog?  Why not?

The whole purpose of discoverability is to introduce the user to options they didn't know were available.  How does hosting an addon with thousands of others on a website aid in this endeavor?  If the user already knows they want to change the close button, there is essentially no difference between searching for information about browser.tabs.closeButtons and searching for which addon they need. 


Where is the discussion about the validity of this bug?  Is Jared just unilaterally making these decisions?  None of the arguments for it seem coherent.  Why does this bug make Firefox better?

Comment 40

[Tim Nguyen :ntim]

(In reply to tyaremco from comment #39)
> Sorry, where is the explanation for this bug?  You know, what are the
> reasons for it to exist?
> 
> > The browser.tabs.closeButtons pref is only discoverable via about:config. 
> 
> Yes, so are many prefs.  Why is this is even mentioned?
> 
> > It provides other locations for the tab close buttons
> 
> It provides ONE other location: the end of the tabbar.
> 
> > but none that we plan to move towards in the future.
> 
> So, modify the pref?  Why not?
> 
> > These would be better supported and more discoverable if they were implemented by an add-on.
> 
> How could a feature already baked into Firefox be better supported by an
> entity other than Mozilla?  
> 
> Wouldn't it also be more discoverable if it was say, put into an options
> dialog?  Why not?
> 
> The whole purpose of discoverability is to introduce the user to options
> they didn't know were available.  How does hosting an addon with thousands
> of others on a website aid in this endeavor?  If the user already knows they
> want to change the close button, there is essentially no difference between
> searching for information about browser.tabs.closeButtons and searching for
> which addon they need. 
> 
> 
> Where is the discussion about the validity of this bug?  Is Jared just
> unilaterally making these decisions?  None of the arguments for it seem
> coherent.  Why does this bug make Firefox better?

I'm guessing not much people use the pref ? If more people used it, I'm sure it wouldn't have been removed.

Comment 41

[tyaremco]

> I'm guessing not much people use the pref ? If more people used it, I'm sure
> it wouldn't have been removed.

My point is that it should not be ambiguous why a feature was removed.  Should the community be resigned to guessing about Mozilla's rationale?

Comment 42

[Sylvestre Ledru [:Sylvestre]]

Added in the release notes with the title "browser.tabs.closeButtons hidden preference no longer supported (See the <a href="https://addons.mozilla.org/fr/firefox/addon/no-close-buttons/">No Close Buttons</a> extension for alternative)"

Comment 43

[Jared Wein [:jaws] (please needinfo? me)]

Sylvestre, please adjust the link to remove the locale from the URL. AMO should redirect the user to their requested locale if one is not provided in the link. Note that the link in comment 42 is for French.

Comment 44

[Sylvestre Ledru [:Sylvestre]]

Fixed, thanks

Comment 45

[Jez]

Hah, the removal of this pref is ridiculous.  What harm was it doing?  Worked fine in FF29.  As usual, you point people to addons to restore functionality that used to be built-in to the browser, for no particular reason.

Comment 46

[Jorge Villalobos [:jorgev] (he/him)]

Looking into AMO add-ons, I saw a couple dozen that are using this pref, mostly in two categories: tab add-ons and hidden pref add-ons, notably:

* https://addons.mozilla.org/addon/tab-mix-plus/, 1M ADI
* https://addons.mozilla.org/addon/classic-compact-options/, 152K ADI
* https://addons.mozilla.org/addon/tab-utilities/, 37K ADI
* https://addons.mozilla.org/addon/guiconfig/, 26K ADI
* https://addons.mozilla.org/addon/configuration-mania-4420/, 23K ADI

Looking for tabs-closebutton leads to dozens additional results.

I wouldn't expect these add-ons to break very dramatically due to this change, or the fix to be particularly difficult, however.

Comment 47

[Jj Del Carpio]

It took me a lot of interneting to find this bug. Bugzilla does not show this when searching for the "closeButtons" preference.

I am also bummed on how this decision was made. I respect the developer that proposed it, but it looks like it was an unilateral call without any discussion or input: "I don't use it, then nobody else must".

What is the cost/benefit of removing it vs leaving it. Does removing the feature improve the browser experience? Maybe reduces code complexity? 

Sure, the 20 of us who use it can very well go to userChrome.css and do it. I would have been more accepting if there was an argument on "why", so I can sleep at night. Not to explain "me" but so in the future when coming back we can understand the rationale and not fall for this in the future. Developer B may come with an idea "let's add a closeButtons preference" and do it again since there was no reason explaining why it was a good idea to get rid of it on the first place.

My personal stance, I think it bloats my browser more to have one more extension installed than setting a browser preference. The fact that a preference is not discoverable is not an argument by itself, we'd get rid of 90% of about:config options.

Comment 48

[Chizilla]

Hey!! That's a great idea! Why don't you eliminate everything that's only discoverable through about:prefs so that people can get the preferences back through add-ons only. Then you will be able to say that the reason that "my" broswer used to suck is because of all the add-ons "I" installed.

Pass the blame to the user and to other developers. Genius!!

You noticed that I said "used to", right? Around since Mosaic Netscape and FF28 is my last one. I wish Dolphin would make a windows browser already....

Comment 49

[Dão Gottwald [:dao]]

(In reply to Jj Del Carpio from comment #47)
> What is the cost/benefit of removing it vs leaving it. Does removing the
> feature improve the browser experience? Maybe reduces code complexity?

Yes, it did reduce code complexity.

Comment 50

[Alex Shilov]

What the... I'm just updated my Nightly (I'm not using auto-update) and my sweet close tab button is gone. Now it's in every tab, instead of at the end of the tab strip.
I used browser.tabs.closeButtons=3 for ages, since Phoenix 0.1, since Mozilla Suite 1, you name it. And now it's gone!
I was already know the setting name, and assumed that some clever people could remove the setting. But it took some time to find this bug page. What about users who changed this setting via some addons, or just forgot the setting name, how can they find and write in this bug? Ok, i'm using nightly, how surprising it will be for million stable users.

Dao, as long as I remember you are the member of UX team? Have you done any research for this bug? What is the approximate number of people used this setting based of any collected data? I thought there was some sort of tool to measure it, right? Or it can be found in users sync data, right?

(In reply to Dão Gottwald [:dao] from comment #49)
> (In reply to Jj Del Carpio from comment #47)
> > What is the cost/benefit of removing it vs leaving it. Does removing the
> > feature improve the browser experience? Maybe reduces code complexity?
> 
> Yes, it did reduce code complexity.
And it _broke_ experience! 
In fact, if classicthemerestorer has effect, theme-addons still must support browser.tabs.closeButtons=3 button, right? If so, what complexity of the code are reduced exactly?
Rather than remove the setting, because it hasn't in preference list you could just add it there. There was something similar in Chrome, in chrome://flags/ there are non general settings which are listed and explained for user. It will be good if about:config will have small descriptions from http://kb.mozillazine.org/About:config_entries. 

Let me explain which UX behaviour cases are broken:
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 which number of times what 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, then browser hand I sometimes click two times to change it, now accidentally I could press close button then selecting the tab, it's unacceptable.
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. 

See, there is at least three user cases where browser.tabs.closeButtons=3 is important. So let's get rid of them to reduce code complexity? When doing something for user cases - the complexity increases, it is natural. If you get rid of ALL Firefox code it fit to NO one. No features = no complexity. 

If there was so much complexity let's check this out. In your patch, you removed 96 lines of code, MOST of them are comments or CSS in default theme, (the lines which are currently present in thousands of themes), and added 36 lines of code. It actually about a dozen of somehow significant lines of code are removed. Firefox codebase has about 11 million lines of code, so you reduce complexity for about 0.0000%. You haven't optimize rendering engine, or js-engine, or startup time at all, all you did is broke some users experience.

Comment 51

[Tim Nguyen :ntim]

(In reply to Alex Shilov from comment #50)
> What the... I'm just updated my Nightly (I'm not using auto-update) and my
> sweet close tab button is gone. Now it's in every tab, instead of at the end
> of the tab strip.
> I used browser.tabs.closeButtons=3 for ages, since Phoenix 0.1, since
> Mozilla Suite 1, you name it. And now it's gone!
> I was already know the setting name, and assumed that some clever people
> could remove the setting. But it took some time to find this bug page. What
> about users who changed this setting via some addons, or just forgot the
> setting name, how can they find and write in this bug? Ok, i'm using
> nightly, how surprising it will be for million stable users.
> 
> Dao, as long as I remember you are the member of UX team? Have you done any
> research for this bug? What is the approximate number of people used this
> setting based of any collected data? I thought there was some sort of tool
> to measure it, right? Or it can be found in users sync data, right?
No he is not an UX member. Yes, we have telemetry, and I'm sure most users don't even know or use this prefs. You can ask the firefox-dev mailing list, they might have your answer.

> (In reply to Dão Gottwald [:dao] from comment #49)
> > (In reply to Jj Del Carpio from comment #47)
> > > What is the cost/benefit of removing it vs leaving it. Does removing the
> > > feature improve the browser experience? Maybe reduces code complexity?
> > 
> > Yes, it did reduce code complexity.
> And it _broke_ experience! 
> In fact, if classicthemerestorer has effect, theme-addons still must support
> browser.tabs.closeButtons=3 button, right? If so, what complexity of the
> code are reduced exactly?
Add-ons build their own code to recreate the pref.


> Let me explain which UX behaviour cases are broken:
> 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 which number of times what 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.
Note that the tab width stays in place for a few seconds. Also, you can middle click tabs to close them, it's a very handy trick I use to close tabs quickly.

> 2) Then I have 100+ tabs open tab width are 30px, then browser hand I
> sometimes click two times to change it, now accidentally I could press close
> button then selecting the tab, it's unacceptable.
Note that if you have lots of tabs, the close button will only appear for the selected tab. So there's no chance of closing a tab while selecting it.

> 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. 
Middle clicking the tab to close it is your friend, it's fast and requires just one hand.


> If there was so much complexity let's check this out. In your patch, you
> removed 96 lines of code, MOST of them are comments or CSS in default theme,
> (the lines which are currently present in thousands of themes), and added 36
> lines of code. It actually about a dozen of somehow significant lines of
> code are removed. Firefox codebase has about 11 million lines of code, so
> you reduce complexity for about 0.0000%. You haven't optimize rendering
> engine, or js-engine, or startup time at all, all you did is broke some
> users experience.
It does reduce lots of code complexity, especially for future tab code we'll introduce. It removes the close button at the end of the tab bar and the CSS and javascript related to it.

Comment 52

[Tim Nguyen :ntim]

(In reply to Alex Shilov from comment #50)
You might also want to post this to the firefox-dev mailing list, this is not a place for discussion.

Comment 53

[Alex Shilov]

Thanks Tim

(In reply to Tim Nguyen [:ntim] from comment #51)
> No he is not an UX member. Yes, we have telemetry, and I'm sure most users
> don't even know or use this prefs. You can ask the firefox-dev mailing list,
> they might have your answer.
I've just sent the mail to list, thanks. But does that mean you haven't get this data yet and just assumed that nobody using hidden prefs?

> Add-ons build their own code to recreate the pref.
Yes, but I now have to find and try this addon, when I didn't need it before. Isn't much addons affect browser performance?
 
> > Let me explain which UX behaviour cases are broken:
> > 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 which number of times what 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.
> Note that the tab width stays in place for a few seconds. 
No it isn't, the tab moving animation starts immediately. 

> ... Also, you can
> middle click tabs to close them, it's a very handy trick I use to close tabs
> quickly.
Yes, I know. But this is very different user case, right? You don't even need close button if you have middle click. For me it was never convenient to press scrolling wheel (because it wheel, it doesn't feel like button), so lets assume there is no middle click.

 
> > 2) Then I have 100+ tabs open tab width are 30px, then browser hand I
> > sometimes click two times to change it, now accidentally I could press close
> > button then selecting the tab, it's unacceptable.
> Note that if you have lots of tabs, the close button will only appear for
> the selected tab. So there's no chance of closing a tab while selecting it.
Try click some tab twice. Not even double click but twice. You see that second click close the tab if it on close button. 
Excuse my english, "then browser hand" - I mean "when browser hang (goes unresponsive)", just typo =). When i have 100+ tabs (actually 100 active tabs from 200-300 total tabs) browser hangs often. I need to click twice sometimes.

> > 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. 
> Middle clicking the tab to close it is your friend, it's fast and requires
> just one hand.
> 
> 
> > If there was so much complexity let's check this out. In your patch, you
> > removed 96 lines of code, MOST of them are comments or CSS in default theme,
> > (the lines which are currently present in thousands of themes), and added 36
> > lines of code. It actually about a dozen of somehow significant lines of
> > code are removed. Firefox codebase has about 11 million lines of code, so
> > you reduce complexity for about 0.0000%. You haven't optimize rendering
> > engine, or js-engine, or startup time at all, all you did is broke some
> > users experience.
> It does reduce lots of code complexity, especially for future tab code we'll
> introduce. It removes the close button at the end of the tab bar and the CSS
> and javascript related to it.
This is a mistake actually. And Netscape has already made it. See old Joel Spolsky article:
http://www.joelonsoftware.com/articles/fog0000000069.html
"Even fairly major architectural changes can be done without throwing away the code."
Of course I can install the addon. Of course I can install it on my home computers, my office computer, for my parents (if they are not using Chrome yet), for my wife's comp, and tell my friend if they using closeButtons=3 to use addon instead. But this could not happen.

When it is in nightly stage may be it's better to revert this bug as regression?

Comment 54

[Alex Shilov]

(In reply to Tim Nguyen [:ntim] from comment #52)
> (In reply to Alex Shilov from comment #50)
> this is not a place for discussion.
Why it's not? Bugzilla is for reporting a bugs, discussing a bugs and fixing a bugs. If you doesn't discuss the bugs you can't fix it properly, IMHO. 
Discuss a bug in the all developers list is not that the average user must do. It's inconvenient for me, and Bugzilla has good functionality for discussing the bugs, it sends email by itself to users relative to this bug only.

Also the etiquette page clearly tells me use the bug itself for constructive comments:
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html 
> No private email. Unless the bug owner or another respected project 
> contributor has asked you to email them with specific information, 
> please place all information relating to bugs in the bug itself. 
> Do not send them by private email; no-one else can read them if 
> you do that, and they'll probably just get ignored. If a file 
> is too big for Bugzilla, add a comment giving the file size and 
> contents and ask what to do. 

I've had a tabclose button, now I haven't. This is clearly the bug for me, and bugs must be placed to bugzilla.

So this comment could be considered offtopic, but not the previous ones.

Comment 55

[Ben Bucksch (:BenB)]

Alex, in addition to middle click, you can also use Ctrl-W. When I want to use several tabs in a row, I select the first one, then use Ctrl-W several times to close the tabs.

Comment 56

[Tim Nguyen :ntim]

(In reply to Alex Shilov from comment #54)
Then file a new bug. This bug is clearly to overloaded for more comments.

Comment 57

[Alex Shilov]

(In reply to Ben Bucksch (:BenB) from comment #55)
> Alex, in addition to middle click, you can also use Ctrl-W. When I want to
> use several tabs in a row, I select the first one, then use Ctrl-W several
> times to close the tabs.
Thanks Ben, of course for closing tab I can press Ctrl-W, or Ctrl-F4 - which I use sometimes, but it's not my preferred way. The question is not How I can do something different from habitual way, the question is Why I should do that, if both way works fine till Firefox 32.0a. 
So I prefer selecting tab by the left hand, and closing it by the right hand. But that's not the point, then I browsing - I'd like using mouse alone (in the right hand) w/o keyboard shortcuts, so closing multiple tabs in a row it's now hard for me. 
Also notice that there was very old bug 78414, so keyboard shortcuts not working if page containing Flash (like youtube player) and it selected. So Ctrl-W has no effect on that pages.

When I described UX cases, they are not synthetical, they used by the real user - me. 
> 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 which number of times what 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.
In this case using Ctrl-F4 could slow down my work, because I must using both keyboard and mouse, instead of only mouse.
> 2) Then I have 100+ tabs open tab width are 30px, then browser hand I
> sometimes click two times to change it, now accidentally I could press close
> button then selecting the tab, it's unacceptable.
Shortcuts can't help in this case either.
> 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. 
In this case I can use Ctrl-W, but on my left hand there will be two shortcut positions Ctrl-W and Ctrl-Tab, which will be twice as hard in using.

I have viewed telemetry data (http://telemetry.mozilla.org/), and also have a reply from DevTeam member (Benjamin Smedberg) who states that there are no such telemetry data. So this bugfix cause based on nothing. 

(In reply to Tim Nguyen [:ntim] from comment #56)
> (In reply to Alex Shilov from comment #54)
> Then file a new bug. This bug is clearly to overloaded for more comments.
If so... OK.

Comment 58

[Steve Brecht]

Another voice of displeasure about this being changed.  Firefox has always been about choice and one by one those choices are being stripped away.  At first they were stripped from the menus, then from the setting screens area, and now you're saying "oh, well if no one can find it, let's just take it out entirely".  This is not acceptable to users who have one step at a time adapted to where the setting has moved to, or used add-ons to enable it again.  

I have never used Chrome specifically because of its lack of custom UI options.  Firefox is now backing out options I strongly prefer and it's very disappointing.  It's a trend I would like to see stop before FF is just a shell of what it used to be.

Count me very disappointed that this is considered "FIXED".  I would have to say more accurately it would be marked "STRIPPED".

Comment 59

[PimpUigi]

It is a shell of what it used to be.
Firefox 1.0 had small buttons as an option - gone.
Firefox 1.0 had tabs under the nav bar - gone.
Firefox 1.0 had the tabs close button at the end of the nav bar - gone.

These are things that helped define Firefox.
Chrome is defined by tabs on top and a hamburger button. Now that's what Firefox is. When you conform your identity to be the same as your competitions, you lose your identity and the people you had kept leave too.

Comment 60

[Artem S. Tashkinov]

Wow, great, let's dumb Firefox down even more.

Hey, guys, why don't you just abandon Firefox altogether and start letting people download Google Chrome from your website?

You made me switch from Firefox 28 to Firefox 24 ESR (instead of brain damaged Firefox 29) and seeing this, I will most likely switch to SeaMonkey - the last remaining sane browser which has Gecko as its rendering engine.

Comment 61

[Lukas]

Why on Earth you remove this preference? Now I am closing tabs by mistake. Why must you constantly annoy users? You really do everything to put Firefox down. :(

Comment 62

[Dão Gottwald [:dao]]

(In reply to Lukas from comment #61)
> Now I am closing tabs by mistake.
> Why must you constantly annoy users? You really do everything to put Firefox
> down. :(

You can customize this with add-ons. For instance:

https://addons.mozilla.org/en-US/firefox/addon/no-close-buttons/

https://addons.mozilla.org/en-US/firefox/addon/tabs-closebutton-restored/

If you think we should change how/where we display tab close buttons by default, that would be a separate discussion (the [e-mail] mailing list is the right place for that).

Comment 63

[Aris]

(In reply to Lukas from comment #61)
> Why on Earth you remove this preference? Now I am closing tabs by mistake.
> Why must you constantly annoy users? You really do everything to put Firefox
> down. :(

You can also use Classic Theme Restorer to restore close buttons previous features: https://addons.mozilla.org/addon/classicthemerestorer/

Comment 64

[the-edmeister]

Quite honestly the "browser.tabs.closeWindowWithLastTab" should have been changed to "false" as part of the Bug fix. There is no excuse for closing the window (or exiting Firefox) as a result of accidentally closing the last or sole tab.

Comment 65

[PimpUigi]

(In reply to the-edmeister from comment #64)
> Quite honestly the "browser.tabs.closeWindowWithLastTab" should have been
> changed to "false" as part of the Bug fix. There is no excuse for closing
> the window (or exiting Firefox) as a result of accidentally closing the last
> or sole tab.

Uh, no. That's just as dumb as this bug fix is to begin with.

Comment 66

[Tim Nguyen :ntim]

(In reply to PimpUigi from comment #65)
> (In reply to the-edmeister from comment #64)
> > Quite honestly the "browser.tabs.closeWindowWithLastTab" should have been
> > changed to "false" as part of the Bug fix. There is no excuse for closing
> > the window (or exiting Firefox) as a result of accidentally closing the last
> > or sole tab.
> 
> Uh, no. That's just as dumb as this bug fix is to begin with.

Note that that was the old behaviour.

Comment 67

[Andrew N Dowden]

This is just another reason Mozilla Firefox is lossing market share. While I will still use it, I'm not sure I can continue to recommend it.

I have used this specific feature, set to '1', for so long I had forgeotten where it was. By design (I assume), the developers never really cared whether anyone knew about this feature. I have accidentally closed the wrong tab over twenty times, just in last two weeks.

Keep dumbing down the product, and you will reach 10% market share. (I assume that is your goal.)

Comment 68

[PimpUigi]

Maybe we really should just write in to that email posted and ask them to change their default behavior.
I honestly don't see why anyone would close a tab by accident...but all the extra close buttons not only waste space, but they move! A static close tabs button on the end of the close tabs bar is the way to go because you can close five tabs in a row if you want.

You can already middle click a tab to close it if you wanted a close tabs button on a tab. The whole tab is that button!

Comment 69

[Sylvestre Ledru [:Sylvestre]]

(In reply to PimpUigi from comment #68)
> Maybe we really should just write in to that email posted and ask them to
> change their default behavior.
Indeed. You should write an email on dev-platform ( https://lists.mozilla.org/listinfo/dev-platform ).
You should explain the context, why you think Firefox should have it again, etc.

Comment 70

[Per Olausson]

Strange I have close buttons everywhere? How did that happen? A quick look at about:config. Nope, I still have a user defined setting. Confused.

Oh, someone decided this was a bug? Really? It was a bug that I could choose my user preference for not littering my horizontal display real estate with useless close buttons?

Could you all go and work for Microsoft? There is a place for you there, I am sure. They are also about denying customisation and friendly user experience to its users.

Off to hunt for a new browser now. Hopefully one which understands that "The Customer knows best".

Comment 71

[cousteau]

(In reply to PimpUigi from comment #68)
> I honestly don't see why anyone would close a tab by accident...
I have done this several times.  This was one of the reasons for me to do this.  I find the close buttons more harmful than useful.  (Actually I don't see them useful at all)

> all the extra close buttons [...] waste space
This was another reason.  My screen is a tiny 1024x768 and I don't want close buttons taking up space. Then again, they only show on the active tab anyway.

> You can already middle click a tab to close it if you wanted a close tabs
> button on a tab. The whole tab is that button!
This was the third reason why I removed the close buttons; I didn't need them anyway.  I guess Firefox is moving towards compatibility with platforms that do not have a middle button, e.g. touchscreens.  But removing this possibility doesn't make sense in my opinion; it just limits the user's customization freedom.

> ask them to change their default behavior.
Probably they should just add an option on the GUI to add/remove the close buttons, rather than removing it from about:config because "it's not in the GUI".

I'm glad someone pointed out the "No Close Buttons" addon, but having to rely on addons to get the behavior that was available before and that made sense is kind of annoying, specially since sometimes these addons are not easy to find.

I don't like the direction the UI design is moving to; it limits the user's freedom to configure the browser without a justified reason other than "it's not available in the GUI and probably nobody used it anyway".  I wish some more flexibility were added to the UI customization.

Comment 72

[PimpUigi]

I've emailed them and asked them to change the default behavior.
But I maintain you have to be pretty incompetent to close a tab by accident, no matter what the option, to the point that you have to blame the option. That's like admitting a mental handicap.

Wasted space, yes. Inconsistent close button location, yes. Redundant, yes. Two very annoying things, and one slightly annoying thing.

Email and ask them to change the default behavior with me, but don't be all like "I'm closing my tabs by accident! All your fault!" every single browser on the market works like this. It's not a widespread or even small spread issue.

Comment 73

[Sylvestre Ledru [:Sylvestre]]

I'm restricting further comments on this bug. Bugzilla isn't intended as a debate forum. If you want to discuss on this, as said previously, please do it on the dev-platform mailing list (you have to register before sending email).

[Comments are restricted to users with the editbugs privilege -- with privilege comes responsibility, so please consider carefully before commenting if you are able.]

Comment 74

[Matthew N. [:MattN]]

Actually firefox-dev would be a better forum as this is a Firefox change, not a cross-application one.

https://mail.mozilla.org/listinfo/firefox-dev