Closed Bug 626854 Opened 9 years ago Closed 8 years ago

Add a separator after the app tabs in the list all tabs menu

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: faaborg, Assigned: steffen.wilberg)

References

Details

Attachments

(1 file, 3 obsolete files)

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/
Assignee: nobody → steffen.wilberg
Status: NEW → ASSIGNED
Component: General → Menus
QA Contact: general → menus
Summary: Add a splitter after the app tabs in the list all tabs menu → Add a separator after the app tabs in the list all tabs menu
Attached patch patch (obsolete) — Splinter Review
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.
Attachment #513732 - Flags: review?(dao)
Comment on attachment 513732 [details] [diff] [review]
patch

Ugh, this will be bitrotted as soon as bug 625320 lands.
Attachment #513732 - Flags: review?(dao)
Depends on: 625320
Attached patch patch v2 (obsolete) — Splinter Review
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.
Attachment #513732 - Attachment is obsolete: true
Attachment #513852 - Flags: review?(dolske)
Attachment #513852 - Flags: feedback?(dao)
Why should app tabs be listed at all? The button was added to access tabs that are scrolled off-screen.
Component: Menus → Tabbed Browser
QA Contact: menus → tabbed.browser
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.
Attached patch v2, unbitrotted (obsolete) — Splinter Review
Alex and Dao, let's either fix or wontfix this bug, please.
Attachment #513852 - Attachment is obsolete: true
Attachment #528073 - Flags: review?(dao)
Attachment #513852 - Flags: review?(dolske)
Attachment #513852 - Flags: feedback?(dao)
Fixed bitrot from bug 653655.
Attachment #528073 - Attachment is obsolete: true
Attachment #533438 - Flags: review?(dao)
Attachment #528073 - Flags: review?(dao)
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
Attachment #533438 - Flags: review?(dao)
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.
Keywords: uiwanted
(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
No longer blocks: 607226
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Keywords: uiwanted
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.