Closed Bug 865826 Opened 11 years ago Closed 10 years ago

Remove the browser.tabs.closeButtons pref

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 31
Tracking Flags:
Tracking Status
relnote-firefox --- 31+

People

(Reporter: jaws, Assigned: dao)

References

Details

(Keywords: addon-compat, dev-doc-needed)

Attachments

(1 file, 2 obsolete files)

patch
22.63 KB, patch
jaws
: review+
Details | Diff | Splinter Review 
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
I've looked it over, and am interested in working on this as my first bug. Any objections?
Nope, go for it! :)
Assignee: nobody → jwlanham5
Status: NEW → ASSIGNED
James, any progress on this?
Flags: needinfo?(jwlanham5)
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.
Flags: needinfo?(jwlanham5)
Assignee: jwlanham5 → jaws
Whiteboard: [mentor=jaws][lang=js]
I'd like to work on this. Can someone please assign this to me?
Sorry, did not notice you were assigned :)
Assignee: jaws → yati.sagade
Assignee: yati.sagade → dao
Attached patch patch (obsolete) — — Splinter Review 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #8408126 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch
        — 
          — Splinter Review
      

    


  

        Attachment #8408887 -
        Attachment is obsolete: true

        Attachment #8409012 -
        Flags: review?(jaws)

    
    

    
  
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.

        Attachment #8409012 -
        Flags: review?(jaws) → review+

    
    

    
  
Mike, please see the question above in comment #10.
Flags: needinfo?(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.
Flags: needinfo?(mconley)

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/1f5f1fe135b9
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 31

    
    

    
  
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.

    
    

    
  
(In reply to ol.rrm.2008@gmail.com 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.

    
    

    
  
(In reply to Dão Gottwald [:dao] from comment #18)
> (In reply to ol.rrm.2008@gmail.com 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.

    
    

    
  
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.

    
    

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

    
    

    
  
(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.
Keywords: addon-compat

    
    

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

    
    

    
      
  

    
    

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

    
    

    
  
Yeah, you're right. Haha.

    
    

    
      
  

    
    

    
  
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.

    
    

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

    
    

    
  
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.

    
    

    
  
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/

    
    

    
  
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

    
    

    
  
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.

          relnote-firefox:
          --- → ?

    
    

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

    
    

    
  
dao, could you propose some wordings for the release notes? Thanks
By the way, you confirm that it is going to be for 31?
Flags: needinfo?(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.
Flags: needinfo?(dao)

    
    

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

    
    

    
  
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?

    
    

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

    
    

    
  
> 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?

    
    

    
  
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)"

          relnote-firefox:
          ? → 31+

    
    

    
  
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.
Flags: needinfo?(sledru)

    
    

    
  
Fixed, thanks
Flags: needinfo?(sledru)

    
    

    
      
  

    
    

    
  
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.

    
  
Depends on: 1007300

    
  
Depends on: 1008594

    
    

    
  
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.

    
    

    
      
  

    
  
No longer depends on: 1008594

    
    

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

    
    

    
      
  

    
    

    
  
(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.
Flags: needinfo?(dao)

    
    

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

    
    

    
      
  

    
    

    
      
  

    
    

    
  
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.

    
    

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

    
    

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

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  
(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 firefox-dev@mozilla.org mailing list is the right place for that).

    
    

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

    
    

    
  
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.

    
    

    
      
  

    
    

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

    
    

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

    
    

    
  
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!

    
    

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

    
    

    
      
  

    
    

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

    
    

    
  
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.

    
    

    
  
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.]
Restrict Comments: true

    
    

    
  
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
See Also:  → 1694926

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: