There should be a splitter in the List all Tabs menu to denote which tabs are app tabs, and which are normal. App Tab One App Tab Two App Tab Three ----------------- Normal Tab one ...

The UX team is very eager to get this bug landed over the next few days in order to make Beta 11. If anyone can get a patch for this bug posted soon, we will push hard for reviews and approval (even though this isn't blocking). You can view all of the related bugs to clean up the traditional menu bar here: http://areweprettyyet.com/4/traditionalMenu/

Modified popuphidden and _updateTabsVisibilityStatus to not expect a tab and tab.boxObject property. Removed the no longer needed faked tab object for the #sync-tabs-sep separator. Added a new _addSeparatorAfterPinnedTabs method to add the separator, called from popupshowing.

Comment on attachment 513732 [details] [diff] [review] patch Ugh, this will be bitrotted as soon as bug 625320 lands.

Unbitrotted after check-in of bug 625320. This also fixes an error introduced by that bug: Error: this.childNodes[i].tab is undefined Source file: chrome://browser/content/tabbrowser.xml Line: 3587 That's in _updateTabsVisibilityStatus and only happens when overflow occurs. tabIsVisible is not used anywhere, but it could break third party themes. I've also removed the link-preview for "Tabs From Other Computers" per bug 625320 comment 29.

Why should app tabs be listed at all? The button was added to access tabs that are scrolled off-screen.

To see all tabs at a glance, whether app tab or not? To read the title of app tabs, which might have changed to announce new mail etc.? I know, the tab gets highlighted as well. Because it's part of http://areweprettyyet.com/4/traditionalMenu/ ?

(In reply to comment #6) > To see all tabs at a glance, whether app tab or not? Again, app tabs are always visible. > To read the title of app tabs, which might have changed to announce new mail > etc.? I know, the tab gets highlighted as well. They get highlighted and have tooltips. > Because it's part of http://areweprettyyet.com/4/traditionalMenu/ ? And why's that?

generally throughout the product drop down expansion arrows comprehensively include all choices (even though this is really redundant). Other examples include main items in the Firefox split button being available, and split buttons in notifications including the main command (bug 615441). The idea is that users can view all available options together at the same time, without having to visually (and mentally) backtrack. The obvious cost to this is all of the extra redundancy in our secondary UIs. I personally like it, since it doesn't require the user to store any items in memory as they make a choice. It's visually a bit more complex, and interactively a bit simpler. Side issue in this case is exposing app tab titles, but as you point out they do have tooltips as well for that.

Well, the list is only comprehensive depending on where you draw the line. Currently we exclude tabs in other groups. App tabs aren't designed to be transient but to persist in a fixed location, so I think they can totally rely on the icon and the user's spatial memory. I'd rate the cost of the redundancy relatively high, as I find this part of the UI rather cumbersome already.

Alex and Dao, let's either fix or wontfix this bug, please.

Fixed bitrot from bug 653655.

Comment on attachment 533438 [details] [diff] [review] unbitrotted again I think we should: - remove app tabs from this menu - hide the button unless there are more than X (3?) normal tabs, they're overflowing or something like that

The all-tabs-button is the only UI to Tab Groups (it was moved there by bug 625320). I doubt it's a frequently used item though. "Tabs From Other Computers" is present in the traditional History menu, but not the Firefox appmenu. That could be fixed by adding to the Firefox->History appmenu.

(In reply to Steffen Wilberg from comment #13) > The all-tabs-button is the only UI to Tab Groups (it was moved there by bug > 625320). I doubt it's a frequently used item though. For people who actually use tab groups, we put a dedicated button for that on the toolbar. As for *discovering* tab groups, showing the all-tabs button only when there are enough tabs would still take care of this; tab groups are only useful for heavy tab users anyway.

(In reply to Dão Gottwald [:dao] from comment #12) > I think we should: > - remove app tabs from this menu > - hide the button unless ... they're overflowing I second this. The UX branch has been hiding the all-tabs button in non-overflow mode for a while now: https://hg.mozilla.org/projects/ux/rev/a061de2197ff#l4.140 We have to ensure that this doesn't cause the scrollbox to glitch, i.e. continously toggle between overflow and underflow.

(In reply to Frank Yan (:fryn) from comment #15) > (In reply to Dão Gottwald [:dao] from comment #12) > > I think we should: > > - remove app tabs from this menu > > - hide the button unless ... they're overflowing > > I second this. The UX branch has been hiding the all-tabs button in > non-overflow mode for a while now: > https://hg.mozilla.org/projects/ux/rev/a061de2197ff#l4.140 > We have to ensure that this doesn't cause the scrollbox to glitch, i.e. > continously toggle between overflow and underflow. filed bug 714281

bug 714281 and bug 714594 are fixed