Closed Bug 877479 Opened 11 years ago Closed 11 years ago

browser.tabs.autoHide is gone

Categories

(Firefox :: Tabbed Browser, defect)

23 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: dale.a.schouten, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130529 Firefox/23.0 (Nightly/Aurora) Build ID: 20130529004017 Steps to reproduce: I have browser.tabs.autoHide set in about:config and have for a long time. I probably set it via preferences->tabs at some point in the past. Actual results: I restarted my browser for the first time in several days. I normally use Aurora. After restarting, I noticed that I have tabs in my windows where I didn't before. It seems that with a recent Aurora update, autoHiding of browser tabs no longer works (I.e. I see the browser tab even when I only have one tab). When I looked into about:config, it seems that that option has no effect anymore. Expected results: With this setting, when I have only one tab open, I shouldn't see the tab at the top of the window. It still works with my current Firefox (Non Aurora) version 17.0.1.
This is expected behaviour; the option has been removed in bug 855370. You can find solutions in this topic: http://forums.mozillazine.org/viewtopic.php?f=23&t=2706317
Thank you for the information. I consider this a very unfortunate design choice, ironically using the keyword "ux-minimalism" when in fact it does just the opposite, adding useless clutter to the interface. I'm afraid I don't understand the solutions in the link you provided. I see several lines of CSS, but can you enlighten me as to where I would put that CSS to fix Firefox? Is there some config file or something somewhere where it would make sense to add those CSS lines? Thanks!
I see now that those CSS statements go in userChrome.css, though they don't quite work. It looks like the extension is the only real solution for now. Oh well. Time for one of those "Firefox made me sad" feedbacks.
Blocks: 855370
Component: Untriaged → Tabbed Browser
As mentioned in comment #1 this has been removed intentionally by bug 855370. Feel free to try a couple of the solutions in http://forums.mozillazine.org/viewtopic.php?f=23&t=2706317 and if they don't work take the discussion to the forums or mailing lists, please.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Incredible. Does Mozilla actually consist of a big team revolving around the single topic "what shall we regress today?" Do you have any idea how many add-ons I have to install just to keep Firefox as it is, or what it _was_ at the time I chose to install it first? This issue is either a bug or a grave error in the decision process. It should be reopened in the tracker and fixed.
I'm sad to see this feature go. I've had this setting in my user.js preferences since at least 2009. The main reason I stick with Firefox over Chrome is its inherent flexibility and elegance. I hope the team will consider re-adding this functionality or providing a way to re-add this functionality without installing a plugin. As far as I know, there's no easy way to mechanically install a plugin, but it is easy to mechanically install preferences, so "just use the plugin" is an ugly fix.
I should have mentioned that the ability to hide tabs was the primary reason I migrated from IE to Firefox when IE7 came out.
You can still hide tabs Jason, thru a addon unlike IE and Chrome.
This code included into userChrome.css. should work too (or almost). #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; }
"Voting" that the auto-hide tabs feature returns in version 24.x to support traditional functionality. Suggest a "warning' if a user un-checks the "Always show tabs" and that "Always Show tabs" installs with a default of "checked" for novice users so they won't be "confused".
Also suggest that the release notes for 23.x be updated to mention the Hide Tabbar 2.1.0 "plug in" that lessons the annoyance for legacy Firefox users so they have a simple "work around" until the developers "catch up" with legacy user expectations.
(In reply to Jason R. Coombs from comment #12) > I should have mentioned that the ability to hide tabs was the primary reason > I migrated from IE to Firefox when IE7 came out. I totally understand. I was an early adopter of IE 1.x and 2.x for certain websites since Netscape was so "cumbersome" at times ... then the inevitable "bloat" began with IE and I switched over to Firefox starting around version 1.4.x ....might have been 1.2.x ... and this is the first time I ever felt a "need" to file a bug report. Usually I'd just go back to a previous version for a few days, a "fix" release for FF would come out and I'd upgrade to it. I've noticed things seem to get "released" out of Beta a lot faster now ... perhaps TOO fast. 22.0 comes to mind and how "dog slow" it was with Javascript on Yahoo! Mail. It was fixed about 2 weeks later and 22.x works OK now ... if you can find it now that 23.0 is out.
Please add back the ability to hide the tab bar. THE WHOLE THING THAT MAKES FIREFOX GREAT IS THAT IT'S CONFIGURABLE, HACKABLE, EXTENDIBLE, AND CAN BE MADE TO DO OUR BIDDING IN WAYS NO BROWSER CAN. If this is a deliberate design decision that's just sad. Firefox may be starting to lose its way.
The add-on doesn't completely restore the lost function. Nor does the CSS. Removing eight lines of desirable, option-granting code hardly qualifies as "streamlining".
I'm baffled trying to figure out how to hide the new tab button when there's only one tab. This selects the first tab: #tabbrowser-tabs tab[first-tab='true'] This selects the new tab button: #tabbrowser-tabs .tabs-newtab-button DOM Inspector lists the new tab button as the next element after the tabs, so I figured this should select it when there was only one tab: #tabbrowser-tabs tab[first-tab='true'] + .tabs-newtab-button It doesn't, though. I tried selecting it after any tab: #tabbrowser-tabs tab + .tabs-newtab-button and that doesn't work either. Is there an invisible sibling in between that DOM Inspector isn't telling me about?
More and more baffled--neither of these selects anything: tab ~ .tabs-newtab-button .tabs-newtab-button ~ tab Are they not actually siblings? DOM Inspector shows them as children of the same box. Sibling combinators do work as expected on the tabs: tab ~ tab /* selects the second and subsequent tabs */ tab[first-tab='true'] + tab /* selects just the second tab */
I don't understand why this bug is 'unconfirmed' and 'resolved'?? As it worked perfectly before, why is it changed? Please reactivate this feature.
(In reply to clock8 from comment #29) > As it worked perfectly before, why is it changed? Read bug 855370.
Yes I did and also the comments. I'm with the comment of JoeG and many user comments at different web sites. I understand the need to renew software and to remove bugs, but I don't understand the relationship to remove a valuable feature that users want. The background why I'm asking is that new displays tend to be small and narrow and web pages tend to have menus on top, therefore the remaining space to read the contents is often limited. Please understand this as a problem report of a user. It's about the feature, not about the implementation. It can certainly be solved by any other creative idea for a better design as well. So this problem is neither resolved nor invalid.
The downside of depending on extensions for functionality that used to be built in is that we must depend on the developer of the add-on to maintain it through browser upgrades that may break the extension's function. We already experienced that when Mozilla screwed up the back/forward buttons. If Australis doesn't work with this very popular feature, FIX AUSTRALIS, don't remove desired functionality. That is the epitome of bad design.
Since this seems to be the main discussion: patch attached here for restoring back-end support: https://bugzilla.mozilla.org/show_bug.cgi?id=903720 We're talking about changing 2 lines of code here. So many discussions, unhappy users. Think it would it would make sense if someone could give a short explanation why this is worth (after reading 30 bugs & duplicates and hundreds of comments I couldn't find any detailed reason why Backend support had to be removed [after the removal of the GUI function]).
Another user suprirsed to see this go. A good point to make is there isn't anyone on this thread (or anywhere I've looked on the net) who says they're happy to see this feature gone. On a side note, the overly bloated but very useful plugin Tab Mix Plus has an option to hide the tab bar when there's only 1 tab open.
You need to log in before you can comment on or make changes to this bug.