We should re-add the ability to not "Always show the tab bar" as a built-in setting: 1. On lower-end devices having displays with low vertical pixel counts, hiding the tab bar is very helpful in making room for page contents. Installing an add-on on a low-end device to do this would require more resources than if it were a built-in setting. 2. Hiding tabs when they are not needed is a common and natural UI behavior. Quickly surveying my desktop, many mature applications do so: GVim, GNOME Terminal, Files, etc. I believe this behavior is more common than the alternative of always showing tabs. Keeping a single tab open is inconsistent with the majority of applications. 3. The feature itself is lightweight and adds minimal complexity. Requiring the user to install an add-on for a basic configuration is anti-minimalistic. This enhancement would partially or fully revert the change made in bug 855370. The reasons that change are problematic, which I have listed above, were apparently not considered or discussed in that bug. This enhancement is not a duplicate of existing bugs. Bug 903384, bug 901974, and bug 877479 invalidly reported the lack of the "Always show the tab bar" as a fault, when it was an intended change. This bug recognizes that removing the setting was an intended change, and proposes re-adding the setting as an enhancement for the reasons listed above. Bug 855370 proposed removing the feature as an enhancement, so it seems equally valid to propose adding the feature as an enhancement.

I wouldn't be opposed to re-adding the feature, but some changes would need to be made to its ui. A. There must always always be a new tab button somewhere, even when the bar is hidden. We could shrink it and move it, but it needs to be visible as to not confuse any users. Safari has a similar behavior. B. We must find a way to make this work well with Australis. The previous implementation removed the whole bar, which would require us to re-adjust the window controls. Confirming, but a lot of work would need to go into this to make it work.

(In reply to Josiah Bruner [:JosiahOne] from comment #1) > A. There must always always be a new tab button somewhere, even when the bar > is hidden. We could shrink it and move it, but it needs to be visible as to > not confuse any users. Safari has a similar behavior. I'm using the Ctrl+T shortcut to create a new tab, and it is also possible (at least in current versions) to move the "new tab" button onto the main toolbar, so there are ways available already to get it done even with a hidden tabbar.

(In reply to rsx11m from comment #2) > (In reply to Josiah Bruner [:JosiahOne] from comment #1) > > A. There must always always be a new tab button somewhere, even when the bar > > is hidden. We could shrink it and move it, but it needs to be visible as to > > not confuse any users. Safari has a similar behavior. > > I'm using the Ctrl+T shortcut to create a new tab, and it is also possible > (at least in current versions) to move the "new tab" button onto the main > toolbar, so there are ways available already to get it done even with a > hidden tabbar. Correct, but neither of those are adequate enough for normal users. This is the main reason the feature was removed. Most people accidentally remove the tab bar and have no idea on how to add a new tab. We can't expect people to move the button themselves.

Well, browser.tabs.autoHide;true is the default in SeaMonkey, and I haven't seen a single post like "How do I open a new browser tab?" in the MozillaZine forums from any confused user, so that's a somewhat weak argument (I can't talk for Firefox as I'm not following those forums on a regular basis, but right now there are lots of users complaining about browser.tabs.autoHide having been removed). As was initially proposed in bug 455864, the backend could have been left intact and only the UI removed from the prefpane. Thus, reverting that part of your patch in bug 855370 (which is a 3-minute patch) would resolve the issue for users who want the feature on purpose (and those finding about:config should be able to also customize the toolbars as they see fit). It should also be feasible for beta and thus the new 24.0 ESR branch, retaining that feature for organizational users.

(In reply to rsx11m from comment #4) > Well, browser.tabs.autoHide;true is the default in SeaMonkey, and I haven't > seen a single post like "How do I open a new browser tab?" in the > MozillaZine forums from any confused user, so that's a somewhat weak > argument (I can't talk for Firefox as I'm not following those forums on a > regular basis, but right now there are lots of users complaining about > browser.tabs.autoHide having been removed). > > As was initially proposed in bug 455864, the backend could have been left > intact and only the UI removed from the prefpane. Thus, reverting that part > of your patch in bug 855370 (which is a 3-minute patch) would resolve the > issue for users who want the feature on purpose (and those finding > about:config should be able to also customize the toolbars as they see fit). > It should also be feasible for beta and thus the new 24.0 ESR branch, > retaining that feature for organizational users. Seamonkey users will certainly be much more tech-centered than Firefox users. However, I could re-add the backend and about:config pref, but I don't really think we will take the time to support the pref for future features (like bug 851652), until a better front-end is created. I'll start the patch...

Back end support. Flagging Dao for review.

(In reply to zC1sGxwgj from comment #0) > Installing an add-on on a low-end device to do this would require more > resources than if it were a built-in setting. This isn't really true, the overhead is negligible. > Keeping a single tab open is > inconsistent with the majority of applications. Inter-app consistency is not a primary design goal, particularly for aesthetics (as opposed to functionality/interaction). > 3. The feature itself is lightweight and adds minimal complexity. I'm not sure what you're basing this statement on - we removed it because it adds complexity to our maintenance of the code. I don't see any reason to revisit this decision.

Comment on attachment 788533 [details] [diff] [review] Tab bar autohide backend Thanks for writing this up, but I don't think we should do this.

Comment on attachment 788533 [details] [diff] [review] Tab bar autohide backend Killing the review flag because it messes up my queue. Since I don't need to make any changes, I'll just remove it.

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #8) > I don't see any reason to revisit this decision. Hiding the tabs is needed on displays with low vertical pixel counts in order to provide sufficient screen area for page contents. To force users to download an add-on for Firefox to work well on such displays is exclusionary. It is to say we only want Firefox to work well for certain kinds of modern computers as distributed. I am pretty sure that is not a design goal. For instance, I am running Firefox on an Asus X101CH with a 10.1" display, maximum resolution 1024x600. Firefox is painful to use unless you hide UI elements that take up vertical space. You can run it in full screen but that comes with its own pains. I'd guess the tab bar takes up 10% of your vertical screen area! > Inter-app consistency is not a primary design goal, particularly for aesthetics (as opposed to functionality/interaction). User expectation is important in user-interface design. If a user is accustomed to tabs disappearing when all but the last tab is closed, it is troublesome when that does not occur. It is an interruption in their use of the browser. > we removed it because it adds complexity to our maintenance of the code. That could be said of any feature, however minor. I looked at the patches involved and the changes were very modest. Why do you think this feature would be difficult to maintain? At the least, it could be retained as a setting in about:config, which already comes with a warning that changing any settings "voids your warranty".

(In reply to Josiah Bruner [:JosiahOne] from comment #1) > I wouldn't be opposed to re-adding the feature, but some changes would need > to be made to its ui. > > A. There must always always be a new tab button somewhere, even when the bar > is hidden. We could shrink it and move it, but it needs to be visible as to > not confuse any users. Safari has a similar behavior. If a user enables the setting via about:config, they probably know what they are doing and are not going to be surprised when their tabs disappear. There are several easily discoverable ways to open a new tab. > B. We must find a way to make this work well with Australis. The previous > implementation removed the whole bar, which would require us to re-adjust > the window controls. Australias is planned for 25, IIUC, so this is not a problem for the 24 and 24 ESR releases.

(In reply to zC1sGxwgj from comment #11) > Hiding the tabs is needed on displays with low vertical pixel counts in > order to provide sufficient screen area for page contents. To force users > to download an add-on for Firefox to work well on such displays is > exclusionary. It's impossible to accommodate all every use case in Firefox proper, so use cases deemed marginal are excluded, quite intentionally (we can't be all things to all people). Low vertical pixel count displays fall in that bucket. Even ignoring the important of that particular audience, the benefit of this feature is minimal; it only exists when there is only a single tab open, which is yet another subset of usage scenarios. Low bang/buck means we should drop the feature. > User expectation is important in user-interface design. This is vague enough of a statement that it could be used to support any argument :) I don't believe that any significant portion of users have any expectations of behavior here. > Why do you think this feature would be difficult to maintain? Josiah goes into some detail in bug 855370 comment 7, and http://benjamin.smedbergs.us/blog/2005-07-29/the-testing-matrix/ does a good job of explaining some related high-level principles.

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #13) > It's impossible to accommodate all every use case in Firefox proper, so use > cases deemed marginal are excluded, quite intentionally (we can't be all > things to all people). Low vertical pixel count displays fall in that > bucket. Even ignoring the important of that particular audience, the benefit > of this feature is minimal; it only exists when there is only a single tab > open, which is yet another subset of usage scenarios. Low bang/buck means we > should drop the feature. I've reconsidered and no longer support the enhancement, for what it's worth. Some features that improve user experience for small subsets of Firefox users are worthwhile, like accessibility features, but the response to the removal of the original option seems to me no more oppositional than would be expected for the removal of any obscure option. So maybe you are right that the wasted-vertical-space problem I described is marginal. More important then to reduce complexity, however modestly. I would hope though that if this is problematic for many others they will give that feedback.

Well, let's put "complexity" into perspective. De facto the patch adds 8 lines of functional code compared to what bug 855370 introduced (2 lines are just setting pref defaults and 2 more are comments). Thus, I doubt that retaining the backend support for interested users would have impaired development in any way. The other question is: How much "bang" justifies the "buck" in the end, and who decides what the user is supposed to be "interested" in?

I was happy that FF supported it because it was possible for me to use windows instead of tabs (I can close unwanted windows with mouse button much quicker than searching for the tab x to close it). I can understand the change to remove it from the GUI. Inexperienced users may have issues with a missing tab button. However I don't understand why the backend support should be removed. I know where I can find the setting and if some theme breaks and I need to configure the tab bar I can click on File->New tab or FF button and if everything breaks I can go to pref.js directly. What further testing / work is required for this hidden pref setting? If we disable these hidden pref settings, we can disable a few more. For example: Disabling the ability to show the menu bar, disabling the status bar & bookmarks toolbar. Maybe disabling about:config all together and just handle everything through start parameters like Chrome does. All this are features that are off by default, existent since stone-age browsers, used only by a minority and may creating additional work during build creation.

(In reply to sgl4kn from comment #16) > What further testing / work is required for this hidden pref setting? Not much as it seems. There were no automated tests touched by bug 855370 attachment 730460 [details] [diff] [review] (thus assuming that there were none considered necessary in the first place), and attachment 788533 [details] [diff] [review] here would just revert the backend part without reintroducing the associated UI in the prefpane.

I wonder if it's really speading browsing a lot, the removal hiding tabs code - anybody care to do some benchmark? Also there is a CSS mod to do the same (good You can still do it this way) - to work as about:config pref did. userChrome.css code is as follows: #TabsToolbar { border : none !important;} #TabsToolbar { min-height: 0px !important;} #TabsToolbar > toolbarbutton,.tabs-newtab-button { visibility: collapse !important;} #tabbrowser-tabs tab[first-tab='true'][last-tab='true'] { display:none !important; } Which part is faster? Using the hardcoded function or CSS mod to hide it when there is one tab open? Maybe there is a better CSS code that is even faster? I got this code from somewhere (don't rember). :) Is it maybe possible to further hide navigation and title bar with CSS userChrome code? Sorry for so many question but I'm really curious. :D

The userChrome.css code won't work correctly when using the middle mouse button or opening a link in a new tab from the context menu with certain link behavior settings, with the "switch to it immediately" option unchecked (the still active tab remains hidden in the tabbar in this case).

Please reopen this. The fix for Bug 855370 is itself a bug. (Neither the first nor the last time a bugfix has been itself a bug.) Examine the level of vitriol that 855370 has caused in the forums - people really want this feature back. And it is not a trivial number of marginal-case users, either, contrary to Comment 14 here. Add-ons have their own set of issues, so an add-on is not an acceptable circumvention for a bug that was introduced in the development process. I strongly support this enhancement as originally proposed herein.

Since a few comments seem to be inviting feedback... Removing this lightweight (8-line) preference is a huge step backward. I'm not sure what the issue is with allowing users the preference; surely eight lines of code don't pose a huge developmental barrier to Mozilla? If it's a support issue (odd that it would be, because with the option present before, there didn't seem to be any issues), then move it to Advanced prefs or about:config, like everything else. Justification for removal is that its use is a "case deemed marginal". By whom? Certainly not the users who utilize it. The number of users using pipelining, keywords, sync, do not track, FAYT, etc are likely even more "marginal", and yet those features exist (and for good reason) - for those who utilize it, it imparts necessary functionality (at a low cost) that should be a part of the browser's design, not added on. And yet there implementations that should exist only as add-ons, for obvious reasons (e.g. social integration). At the time of this writing, there are ~12k users who are using an experimental add-on to restore the hidden tab bar functionality. That's assuredly a vast underrepresentation of the users who prefer having the option, including those without knowledge of extensions, those for whom a hacky/incomplate workaround isn't sufficient, those using a CSS hack instead (which also doesn't replicate functionality), etc. The "last words" of Bug 855370: "But, if you miss this feature, I direct you too: https://addons.mozilla.org/en-US/firefox/addon/hide-tab-bar-with-one-tab/ Which re-enables this previous ability. Cheers!" Not only is this dismissive, it also points to an inadequate "solution" that relies on another bug.

(In reply to Josiah Bruner [:JosiahOne] from comment #1) > B. We must find a way to make this work well with Australis. If Australis doesn't work with this long-standing popular feature, then fix Australis. I think you've seen enough backlash about this to realize what a poor design decision this is.

As an FYI: the patch attached to this bug was landed in Pale Moon 24 successfully, and users are (very) happy to still have the option available - it is indeed a popular feature. I concur with comment 4 that nobody has ever complained about not knowing how to open a new tab (and making the tab bar appear) if this option is enabled.

(In reply to Mark Straver from comment #23) > As an FYI: the patch attached to this bug was landed in Pale Moon 24 > successfully, and users are (very) happy to still have the option available > - it is indeed a popular feature. Not really, browser.tabs.autoHide;true still has no effect in FF24.

(In reply to Josiah Bruner [:JosiahOne] from comment #1) > I wouldn't be opposed to re-adding the feature, but some changes would need > to be made to its ui. > > A. There must always always be a new tab button somewhere, even when the bar > is hidden. I don't understand why. It's on the File menu. Most novice users depend on the menus, since they've been around since the beginning of GUIs. As others have mentioned in earlier comments, nobody has expressed confusion about how to open a new tab when the tab bar is hidden. > B. We must find a way to make this work well with Australis. Or Fix Australis to work with this popular feature. This bug should be re-evaluated until you make the proper decision to restore the feature that so many people have told you they want. Relying on third-party extensions means relying on third-party developers who may not be willing/able to maintain their extensions over the long haul. We've already seen that happen with the extension that fixed your screw-up of the back/forward buttons.

There is already a "new tab button" - <ctrl>T on the keyboard. That experimental add-on to restore this highly desirable feature, contains a serious bug. It disables the option "Warn me when closing multiple tabs". So we have a Hobson's choice: Either we can hide the tab bar with only one tab, or we can be warned when closing multiple tabs. Most people want both. This extremely popular feature, to hide the tab bar when there is only one tab, must be restored - and not at the expense of some other popular feature. Future developments are not relevant compared to what the user community really wants. Australis will have to conform. To do otherwise is a bug which must be fixed, ergo this bug report. This needs to be fixed before EOL for FF17 in the ESR channel, or the complaints will get much more frequent and shrill. How can we escalate this matter within the Mozilla Foundation?

I have been on the "Nightly update channel" (as it is now called) almost since the beginning, and today for the first time I noticed what everyone else in this bug has been complaining about. I am adding my voice to the complaint. Since the beginning, I appreciated the possibility of removing clutter so as to increase the "real estate" taken up by the page I am viewing. I have had nothing showing on top but the menu bar, with the location window moved into that. Now I have three things: the menu bar (which I restored), the location window and Google search (which I did not want because I use ctrl-k for that), and a very thick, unnecessary tab bar. This is REALLY BAD. I want the menu bar and nothing else. The tab bar should open only when I have more than one tab. I'm going to try to figure out how to restore what I had before. I don't usually comment on bugs simply to vent frustration, but this time it seems to be necessary.

(In reply to Jonathan Baron from comment #28) Welcome to the cause, Mr. Baron. Please add a vote for this bug to be fixed. Up top, in the field named "Importance" there is a link to cast a vote.

So there's already a 3rd-party extension to fix this major screw-up, and it has over 23,000 users. Not to mention that a fix is also in Tab Mix Plus. But, as has been mentioned before, a 3rd-party extension is only useful as long as the developer wants to maintain it. I hope you are paying attention, Mozilla. This feature should be restored as soon as possible. LISTEN TO YOUR USERS!

(In reply to merfius from comment #21) > [...] A hearty "+1" to that explanation. I'm astonished this feature was removed from about:config - did we learn nothing from the Ubuntu/Windows backlash, when they removed power-user preferences? > The "last words" of Bug 855370: > "But, if you miss this feature, I direct you too: > https://addons.mozilla.org/en-US/firefox/addon/hide-tab-bar-with-one-tab/ > Which re-enables this previous ability. Cheers!" > Not only is this dismissive, it also points to an inadequate "solution" that > relies on another bug. Thank you! I'll use that, until the devs fix this self-created bug.

No offense to the author, but even the add-on is not an adequate replacement: the titlebar is no longer able to be hidden, it takes an extra pixel off the top on some setups, and the transition is a great deal jerkier than the previous implementation. However, with the direction of Australis (senseless removal of features and hoping that extension authors will pick up the slack), I'm not optimistic about this regression being reverted.

I'm still not clear on the reasoning as to why this feature needed to be removed. If someone opens up a settings panel and makes the software less functional, shouldn't they have the wherewithal to undo the change? Sounds like a case of PEBCAK to me.

(In reply to Josiah Bruner [:JosiahOne] from comment #5) > However, I could re-add the backend and about:config pref, but I > don't really think we will take the time to support the pref for future > features (like bug 851652), until a better front-end is created. If you need a better front-end I can help with that. You can even preserve the "add tab" button when tabs are hidden, but I'd need to verify your ability to position that next to the full screen button.

(In reply to Omar from comment #33) > I'm still not clear on the reasoning as to why this feature needed to be > removed. If someone opens up a settings panel and makes the software less > functional, shouldn't they have the wherewithal to undo the change? Sounds > like a case of PEBCAK to me. I explained why this feature was removed here: https://bugzilla.mozilla.org/show_bug.cgi?id=855370#c21 (and many times before and after) If we had to keep a mechanism for every feature removed... Man, would we have a lot of super ugly and messy code keeping things together (which means a lot more bugs and resources needed to fix them). The UX Team decided this feature isn't relevant enough for the cost of maintaining the feature (from the code's perspective), so I went ahead and removed it. Even if we keep the pref hidden, we still have to support the code (Which would put us in a worse position since the number of users using the pref would decrease even more). This is why the feature has been removed from the entire code base. This is also why I must retract my previous statement saying we could probably re-add the feature, I really don't think UX will go for that (not to mention the dev team, since again, we'd have to support the feature). In addition, I no longer work (volunteer) on Firefox, I work on Thunderbird now, so if you have any other comments please direct them towards Gavin Sharp (He's Cc'd here as well). Thanks!