596017 - Combine the Panorama button and the List Tabs button and list all tabs+groups in List Tabs drop-down

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Panorama, defect, P1)

Description

[Aza Raskin [:aza]]

* The two buttons do similar things, one at the all-groups level and one at the current group level. These should be combined into a combo button: on the left the Panorama icon and the right a small drop-down arrow.
* The drop-down should now show tabs from all groups, with the current group on top, each group separated by a horizontal separator and named (in standard menu form).

Comment 1

[Esteban Böhmecke [:skele]]

What about leaving the button as it is and activate a dropdown menu when you do a long-press on that button? :>

Comment 2

[Aza Raskin [:aza]]

Long-presses are (1) undiscoverable and (2) time-dependent which is rarely good. Would prefer a split button.

Assigned to Shorlander for the visual design of the button.

Comment 4

[Michael Yoshitaka Erlewine [:mitcho]]

Shorlander/Aza, please take the thoughts on bug 587538 into account as you reconsider the Panorama and list tabs buttons.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

We need a design here. I agree that we probably want a combobutton approach where the primary action is opening Panorama, and the secondary is to quickly switch between groups.

Comment 6

[ithinc]

(In reply to comment #0)
> * The drop-down should now show tabs from all groups, with the current group on
> top, each group separated by a horizontal separator and named (in standard menu
> form).
Maybe make each group a submenu would be better?

Comment 7

[Aza Raskin [:aza]]

Attachment: Sketch of Panorama Combo Button

Attached a sketch of an idea. Still needs to be made by Horlander for Mac, Windows, and Linux.

Comment 8

[(mostly gone) XtC4UaLL [:xtc4uall]]

If you set "browser.allTabs.previews" to "true" you get the "new", but still non-default Tab Preview Button/Function.

Will this be taken into Account?

Comment 9

[Aza Raskin [:aza]]

My understanding was that feature will be going away, but please start another bug for that.

Comment 10

[ithinc]

Maybe all groups (without expanding) and all orphans, a separator, and all visible tabs is enough. A hidden preference could be added for whether to expand groups.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Aligned drop down, no hover state

vertically align the panorama button and the all tabs drop down.  It is unusual for any control on OS X (with the exception of the traffic light window controls) to have any form of hover state.

Comment 12

[Aza Raskin [:aza]]

Attachment: Menu for the combined list

The drop-down should list tabs from all tabs in that window. See the attachment for how this looks.

Comment 13

[ithinc]

I preferred the following:

Active Tab of Group1 | Group1[n] (show "Group1[n]" as acceltext)
Active Tab of Group2 | [n] (if no group name, show only [n])
Orphan Tab 1
Orphan Tab 2
------------------------------
Tab 1
Tab 2
Tab 3

Comment 14

[ithinc]

If a hidden expand or not preference is set, the group items may be expanded as a menu.

Comment 16

[alexander :surkov (:asurkov)]

(In reply to comment #15)
> *** Bug 609625 has been marked as a duplicate of this bug. ***

Could the button be placed near of application tabs since application tabs can be used to switch between groups like panorama button. I find annoying to move mouse through whole screen often because apps tabs and panorama buttons are "hot" UI controls.

Comment 17

[Ian Gilman [:iangilman]]

Raymond, can you take this on?  It's our only bug that's actually marked as blocking Beta8, so we should take care of it sooner than later (Anant has been doing great work, but his availability is unpredictable).  If there are any things about the design that are unclear, please ping Aza about it.

Comment 18

[Caspy7]

Can right clicking please bring up the menu as well?
I rather don't want to work to click the little down arrow to bring up the list.  

The limited size of the target area is my greatest concern for this feature.

Comment 19

[mindugo]

(In reply to comment #12)
> Created attachment 485888 [details]
> Menu for the combined list
> 
> The drop-down should list tabs from all tabs in that window. See the attachment
> for how this looks.

I would prefer to have expandable/collapsible groups in this drop-down. It is much easier to navigate between groups with lots of tabs in them when they are collapsed. In such case if a group title is clicked instead of particular tab, the first tab from that group will be displayed.

Comment 20

[Raymond Lee [:raymondlee]]

Attachment: WIP v1

Comment 21

[Raymond Lee [:raymondlee]]

Attachment: WIP v2

Things are missing:
* Remove the all tabs button and other code
* Ensure the new popup work with sync service (Weave)
* Update the design of the combo button for Windows and Linux

Ian: If you have time, please give me some feedback for the patch

Aza/Alex: Could you provide me the UI design of the combo button for Windows and Linux

Comment 22

[Ian Gilman [:iangilman]]

Comment on attachment 492329 [details] [diff] [review]
WIP v2

Looks good so far. I don't know that much about the stuff outside of browser-tabview.js; that'll definitely need to be reviewed by someone else when the time comes. 

Also, you might check in with Aza on the full sequence of tabs. Looks pretty good to me, though I think I would put orphan tabs between unnamed groups and app tabs, so app tabs were at the very bottom. I believe that would make the order like so: 

* Active Group
* Named Groups
* Unnamed Groups
* Orphan Tabs
* App Tabs

Comment 23

[ithinc]

Is it necessary to separate App Tabs from the Active Group? I prefer Visible Tabs that "List all tabs" now shows.

Comment 24

[Raymond Lee [:raymondlee]]

Attachment: v1

Implemented the order suggested by Ian

* Active Group
* Named Groups
* Unnamed Groups
* Orphan Tabs
* App Tabs


I've only updated the style of combo button on Mac since there is only MAC design attached to this bug.  However, I find it really hard to click on the little drop arrow now because it's very small.  

@Aza/Horlander: Could you apply the patch and try it on a MAC?  Still need design for Windows and Linux.

Comment 25

[The 8472]

Stuffing all existing tabs into the dropdown would make the dropdown less useful on widescreen monitors in scenarios where you have many tabs open because it would introduce scrolling. If only the tabs of the current group are displayed then no scrolling is required in most cases.

Since hovering the mouse over the tiny scroll triangles are the only way to nagivate through the dropdown i think it should be avoided, especially since the current scrolling position can vary depending on which tab is open, which can make it less useable.

Maybe only the current tabs should be displayed in the dropdown itself and the other groups should be put as sublists (like submenus) at the end. Or they should be foldable.

Comment 26

[Ian Gilman [:iangilman]]

Comment on attachment 493343 [details] [diff] [review]
v1

Why all the code to update the menu dynamically? Are groups and tabs actually going to be coming and going while the menu is up?

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

This can wait until beta9, imo.

Comment 28

[Raymond Lee [:raymondlee]]

(In reply to comment #26)
> Comment on attachment 493343 [details] [diff] [review]
> v1
> 
> Why all the code to update the menu dynamically? Are groups and tabs actually
> going to be coming and going while the menu is up?

Yes, it's possible.  If you look at the current alltabs-popup code, they also handle tabOpen and tabClose.
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#3503

Comment 29

[Dão Gottwald [:dao]]

(In reply to comment #28)
> (In reply to comment #26)
> > Comment on attachment 493343 [details] [diff] [review] [details]
> > v1
> > 
> > Why all the code to update the menu dynamically? Are groups and tabs actually
> > going to be coming and going while the menu is up?
> 
> Yes, it's possible.

It's possible, yet unlikely. TabClose should probably be handled to keep the popup working. But TabOpen doesn't seem like an interesting case and may not be worth the code.

Comment 30

[Raymond Lee [:raymondlee]]

Attachment: V1

Removed the all tabs button

Comment 31

[Ian Gilman [:iangilman]]

Comment on attachment 494336 [details] [diff] [review]
V1

(In reply to comment #29)
> It's possible, yet unlikely. TabClose should probably be handled to keep the
> popup working. But TabOpen doesn't seem like an interesting case and may not be
> worth the code.

Raymond, can you slim it down to just TabClose? I'm concerned that the current implementation is trying to be comprehensive, but still doesn't cover all the cases; better to stick to the minimum necessary.

Comment 32

[Raymond Lee [:raymondlee]]

Attachment: v1

Removed the code for TabOpen.

Comment 33

[Ian Gilman [:iangilman]]

Comment on attachment 494639 [details] [diff] [review]
v1

Looks good to me.  I suggest Dao for review.

Comment 34

[Raymond Lee [:raymondlee]]

(In reply to comment #33)
> Comment on attachment 494639 [details] [diff] [review]
> v1
> 
> Looks good to me.  I suggest Dao for review.

Waiting for the combo button design for Windows and Linux so will request a review once the design is implemented on both platforms

Comment 35

[Kevin Hanes]

Beta8 has 1 bug left on it, moving our blockers to b9

Comment 36

[Stephen Horlander [:shorlander]]

(In reply to comment #34)
> (In reply to comment #33)
> > Comment on attachment 494639 [details] [diff] [review] [details]
> > v1
> > 
> > Looks good to me.  I suggest Dao for review.
> 
> Waiting for the combo button design for Windows and Linux so will request a
> review once the design is implemented on both platforms

After looking at this it looks like the patch is just using a menu-button which should pickup the default menu-buttons styling.

If that doesn't look right it would probably be outside the scope of this bug and we should address any issues in a separate bug.

Comment 37

[Michael Lefevre]

I'm not sure there's any point in raising this at this moment, but there was a bit of an outcry from people who didn't like the panorama feature, and the response (now documented in a couple of support things) is "if you don't want it, just hide the button and it won't affect anything".

I assume this change will mean that people who have hidden the panorama button will find the list tabs button disappears too.

Comment 38

[Dave Garrett]

(In reply to comment #37)
There are still people who refuse to use anything past Firefox 2. If people want something different, they'll use an addon to "make it like the old version" all over again, just like every past major Firefox version. Meanwhile, the other few hundred million users will have a browser written for them as best is possible. Besides, no functionality is being removed in this bug, just merged.

> I assume this change will mean that people who have hidden the panorama button
> will find the list tabs button disappears too.

--> bug 614904

Comment 39

[rob64rock]

This bug 611571 should block bug 596017, if what is stated in the original comment is true here: https://bugzilla.mozilla.org/show_bug.cgi?id=611571#c0

Comment 40

[rob64rock]

(In reply to comment #39)
> This bug 611571 should block bug 596017, if what is stated in the original
> comment is true here: https://bugzilla.mozilla.org/show_bug.cgi?id=611571#c0

Nevermind: "open tabs from other browser" can already be accessed directly from the "list all tabs" button!

Comment 42

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Drugoy, you should probably read this a few times: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 43

[Michael Lefevre]

@KWierso: Think it's a bit beyond etiquette, with the level of abuse and the stealing of other people's handles/names. I suspect his bugzilla accounts are getting deleted, as each posting is from a different email address. So just as soon as someone with privileges sees the latest batch of abusive comments...

Comment 48

[LegNeato]

As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if  you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)

Comment 49

[Gervase Markham [:gerv]]

Another account disabled. Please report any further difficulties in the #bmo channel.

Gerv

Comment 50

[rob64rock]

(In reply to comment #49)
> Another account disabled. Please report any further difficulties in the #bmo
> channel.
> 
> Gerv

Where exactly is that? The troll is back here: https://bugzilla.mozilla.org/show_bug.cgi?id=598921#c43 and here: https://bugzilla.mozilla.org/show_bug.cgi?id=598991#c6

We have an infestation that just won't go away.

Comment 51

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #50)
> (In reply to comment #49)
> > Another account disabled. Please report any further difficulties in the #bmo
> > channel.
> > 
> > Gerv
> 
> Where exactly is that?

#bmo is an IRC channel on irc.mozilla.org for discussing Bugzilla.Mozilla.Org.

*Please* limit comments here to discussions of this bug.

Comment 52

[Raymond Lee [:raymondlee]]

Attachment: v2

Based on the comment#36, use the default style of menu-button for the button.

Comment 53

[Raymond Lee [:raymondlee]]

(In reply to comment #52)
> Created attachment 501944 [details] [diff] [review]
> v2
> 
> Based on the comment#36, use the default style of menu-button for the button.

Passed try

Comment 54

[Ian Gilman [:iangilman]]

Comment on attachment 501944 [details] [diff] [review]
v2

Looks fine as far as I can tell; assigning to Dao for review.

Comment 55

[Dão Gottwald [:dao]]

Comment on attachment 501944 [details] [diff] [review]
v2

I haven't applied and tried the patch yet, but:

>   prefName: "browser.allTabs.previews",
>   readPref: function allTabs_readPref() {
>-    var allTabsButton = document.getElementById("alltabs-button");
>-    if (!allTabsButton)
>-      return;
>-
>-    if (gPrefService.getBoolPref(this.prefName)) {
>-      allTabsButton.removeAttribute("type");
>-      allTabsButton.setAttribute("command", "Browser:ShowAllTabs");
>-    } else {
>-      allTabsButton.setAttribute("type", "menu");
>-      allTabsButton.removeAttribute("command");
>-      allTabsButton.removeAttribute("oncommand");
>-    }
>   },

Remove this method, as it's dead now, and fix up the call sites.

Comment 56

[(mostly gone) XtC4UaLL [:xtc4uall]]

I tried the Tryserver Build (http://hg.mozilla.org/try/rev/524804dbdac3) and noticed that the Favicons for the listed Site's Tabs aren't shown anymore. Is that intended? It looks a bit strange since there seems to be a 1st Column left of Space for that Purpose, no?

Comment 57

[Michael]

I'm not sure that combining them is necessarily a good thing.  The nice thing about Panorama is that you can view and switch between only those tabs that are relevant in your current context.  (I use it in the same way that I do virtual desktops - to see only those things that are relevant to what I'm working on.)  By combining them to see all tabs at once, you lose the context sensitivity of the tab display, and wind up with far more tabs than you may have been expecting.

Note: if you do keep the merged design, it would make sense for switching to a tab in a different group to cause the group containing that tab to be displayed, rather than the current group.  That maintains the correct context for that tab, rather than risking pulling it into the current group.  (This is also consistent with OS X's Spaces behavior.)

Comment 58

[Raymond Lee [:raymondlee]]

Attachment: v2

(In reply to comment #55)
> Comment on attachment 501944 [details] [diff] [review]
> v2
> 
> I haven't applied and tried the patch yet, but:
> 
> >   prefName: "browser.allTabs.previews",
> >   readPref: function allTabs_readPref() {
> >-    var allTabsButton = document.getElementById("alltabs-button");
> >-    if (!allTabsButton)
> >-      return;
> >-
> >-    if (gPrefService.getBoolPref(this.prefName)) {
> >-      allTabsButton.removeAttribute("type");
> >-      allTabsButton.setAttribute("command", "Browser:ShowAllTabs");
> >-    } else {
> >-      allTabsButton.setAttribute("type", "menu");
> >-      allTabsButton.removeAttribute("command");
> >-      allTabsButton.removeAttribute("oncommand");
> >-    }
> >   },
> 
> Remove this method, as it's dead now, and fix up the call sites.

Fixed that. Also, it should show the favicons in the popup menu.

Comment 59

[Dão Gottwald [:dao]]

Comment on attachment 502428 [details] [diff] [review]
v2

>   prefName: "browser.allTabs.previews",

Also unused.
http://mxr.mozilla.org/mozilla-central/search?string=browser.allTabs.previews

Comment 60

[Raymond Lee [:raymondlee]]

(In reply to comment #57)
> I'm not sure that combining them is necessarily a good thing.  The nice thing
> about Panorama is that you can view and switch between only those tabs that are
> relevant in your current context.  (I use it in the same way that I do virtual
> desktops - to see only those things that are relevant to what I'm working on.) 
> By combining them to see all tabs at once, you lose the context sensitivity of
> the tab display, and wind up with far more tabs than you may have been
> expecting.
> 
> Note: if you do keep the merged design, it would make sense for switching to a
> tab in a different group to cause the group containing that tab to be
> displayed, rather than the current group.  That maintains the correct context
> for that tab, rather than risking pulling it into the current group.  (This is
> also consistent with OS X's Spaces behavior.)

The merged design is that when you pick a tab in another group, it would hide tabs in the tabbar, switch to that group and display tabs in that group.  I believe it matches what you want, right?

Comment 61

[Raymond Lee [:raymondlee]]

(In reply to comment #59)
> Comment on attachment 502428 [details] [diff] [review]
> v2
> 
> >   prefName: "browser.allTabs.previews",
> 
> Also unused.
> http://mxr.mozilla.org/mozilla-central/search?string=browser.allTabs.previews

Dao: do you think I should remove the whole "allTabs" object since I think it's not being used now?

Comment 62

[Dão Gottwald [:dao]]

No, only that property isn't used.

Comment 63

[Raymond Lee [:raymondlee]]

Attachment: v2

(In reply to comment #59)
> Comment on attachment 502428 [details] [diff] [review]
> v2
> 
> >   prefName: "browser.allTabs.previews",
> 
> Also unused.
> http://mxr.mozilla.org/mozilla-central/search?string=browser.allTabs.previews

Removed that property

Comment 64

[Dão Gottwald [:dao]]

(In reply to comment #63)
> > http://mxr.mozilla.org/mozilla-central/search?string=browser.allTabs.previews
> 
> Removed that property

You missed firefox.js.

Comment 65

[Dão Gottwald [:dao]]

Comment on attachment 502432 [details] [diff] [review]
v2

>--- a/browser/base/content/browser-tabview.js
>+++ b/browser/base/content/browser-tabview.js

>     let brandShortName = brandBundle.getString("brandShortName");
>-    let title = gNavigatorBundle.getFormattedString("tabView2.title", [brandShortName]);
>+    let title = 
>+      gNavigatorBundle.getFormattedString("tabView2.title", [brandShortName]);
>     return this.windowTitle = title;

>         self._initFrame(function() {
>-          let tabItem = self._window.GroupItems.getNextGroupItemTab(event.shiftKey);
>+          let tabItem = 
>+            self._window.GroupItems.getNextGroupItemTab(event.shiftKey);

You're adding trailing spaces here. These changes don't seem beneficial in the first place, please drop them.

Comment 66

[Raymond Lee [:raymondlee]]

Attachment: v2

Updated the patch to remove browser.allTabs.previews in firefox.js and dropped the changes mentioned in #65

Comment 67

[Kevin Hanes]

bugspam (moving b9 to b10)

Comment 68

[Kevin Hanes]

bugspam (removing b9)

Comment 69

[Mike Beltzner [:beltzner, not reading bugmail]]

Actually, after talking with Limi, we've decided that the safest way forward will be to remove the Panorama button from the toolbar by default. Users can customize their toolbar to re-add it, or use the menu options to get in/out.

I'll file a bug to track that work, but for now let's take this off the list. I suspect Ian will agree, as he'd mentioned that this was one of the riskier changes left.

Comment 70

[Aza Raskin [:aza]]

Does this mean that, by default on a vanilla install of Firefox, Panorama won't have an affordance?

Comment 71

[Caspy7]

(In reply to comment #69)
> Actually, after talking with Limi, we've decided that the safest way forward
> will be to remove the Panorama button from the toolbar by default. Users can
> customize their toolbar to re-add it, or use the menu options to get in/out.

I suppose I should point out that this will, in effect, remove Panorama from Firefox 4 for the vast majority of users (pretty well everyone we have in mind when designing).

If that IS NOT your intent, then the discussion on this topic ought to continue, allowing for the less-than-optimal-but-workable solution over the shooting-for-perfection-but-making-things-worse solution.

If that IS your intent, well, hold on to your shoelaces, I suspect you'll be hearing about this one.

Comment 72

[Luke Iliffe (Harlequin99)]

(In reply to comment #70)
> Does this mean that, by default on a vanilla install of Firefox, Panorama won't
> have an affordance?

Even less if bug 624588 is fixed. Removing the UI and keyboard access by default seems underselling a great new unique feature.

Comment 73

[Kevin Hanes]

(In reply to comment #69)
> Actually, after talking with Limi, we've decided that the safest way forward
> will be to remove the Panorama button from the toolbar by default. Users can
> customize their toolbar to re-add it, or use the menu options to get in/out.
> 
> I'll file a bug to track that work, but for now let's take this off the list. I
> suspect Ian will agree, as he'd mentioned that this was one of the riskier
> changes left.

I really think that bug 624588 is a much better solution here. 

Removing the button makes Panorama effectively undiscoverable. I can understand frustration with accidentally entering Panorama, but a button is a very intentional action. And even if someone does accidentally enter it, no harm is done; the user can exit panorama (either by button clicking, entering a tab, or hitting the close button) and be returned to their tabbed browser unharmed.

Comment 75

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #73)
> but a button is a very intentional action.

Note as well that the button does have a tooltip that says "group your tabs".

I personally understand and agree with the punting of this bug to the future. I am opposed, however, to the removal of the Panorama button from the default toolbar set.

Comment 76

[Siddhartha Dugar [:sdrocking]]

Mockups don't fit with the new layout from Bug 597269

Comment 77

[Dão Gottwald [:dao]]

(In reply to comment #69)
> Actually, after talking with Limi, we've decided that the safest way forward
> will be to remove the Panorama button from the toolbar by default. Users can
> customize their toolbar to re-add it, or use the menu options to get in/out.

filed bug 626500 on this

Comment 78

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #70)
> Does this mean that, by default on a vanilla install of Firefox, Panorama won't
> have an affordance?

Yes, precisely.

Ian and I agreed that there's too much risk remaining in this bug in terms of design and implementation, and further agreed that Panorama should be shipped and made available to those who want to use it.

I'd support a change which adds the Panorama button to the toolbar when the feature is first activated from the menu, as well, or when using the keyboard shortcut. However, we're actively trying to avoid cases where users can accidentally activate Panorama due to the number of dataloss and memory usage bugs remaining and our shipping timeline.

A painful, but I think virtuous, decision.

Comment 79

[Paul [pwd]]

Given the decision, would there be time to implement bug 618791 so we still ship with some tab management by default?

Comment 82

[Raymond Lee [:raymondlee]]

Do we still want to implement this?

Comment 83

[Tim Taubert [:ttaubert] (inactive)]

FTR, bug 589465 is an alternative for this bug. Now we'd need to figure out what UI/UX folks think about these two.

Comment 84

[Tiger.711]

Attachment: Combined drop-down menu for the combined button

Comment 85

[Tiger.711]

Also middle-click on button can instantly create new group and switch to it.

Comment 86

[Paul [pwd]]

At this point, especially given the food for thought that bug 564934 has provided, it may be a good idea to look into the idea of displaying the current tab group in a panel by default. If there are too many tabs, we can switch to list view as per what Windows Task Bar does. And should a user want additional options they can enter an immersive Panorama experience that would allow for moving tabs to different groups or creating different groups all together.

Comment 87

[ael]

This add-on does something similar: https://addons.mozilla.org/en-us/firefox/addon/tabgroups-menu/

Comment 88

[Joe Wilson]

Oh my god, Aza. You are a real destroyer.
Leave 'list all tabs' button alone!

Comment 89

[yayu]

This add-on also does something similar: https://addons.mozilla.org/en-us/firefox/addon/pano/

Comment 90

[Tim Taubert [:ttaubert] (inactive)]

Panorama is not meant to be discoverable and will not be anytime soon, if at all. This functionality can certainly be provided by add-ons so I don't think we want to have this as a core feature.