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

RESOLVED WONTFIX

Status

P1
normal
RESOLVED WONTFIX
8 years ago
3 years ago

People

(Reporter: aza, Unassigned)

Tracking

Trunk
Future

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(5 attachments, 8 obsolete attachments)

(Reporter)

Description

8 years ago
* 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).
(Reporter)

Updated

8 years ago
Assignee: nobody → shorlander
blocking2.0: --- → ?
OS: Mac OS X → All
Hardware: x86 → All
What about leaving the button as it is and activate a dropdown menu when you do a long-press on that button? :>
(Reporter)

Updated

8 years ago
Summary: Combine the Panorama button and the List Tabs button → Combine the Panorama button and the List Tabs button and list all tabs+groups in List Tabs drop-down
(Reporter)

Comment 2

8 years ago
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.
Duplicate of this bug: 587538
Shorlander/Aza, please take the thoughts on bug 587538 into account as you reconsider the Panorama and list tabs buttons.
Priority: -- → P2
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.
blocking2.0: ? → beta8+
Blocks: 597043

Comment 6

8 years ago
(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?
(Reporter)

Comment 7

8 years ago
Created attachment 478730 [details]
Sketch of Panorama Combo Button

Attached a sketch of an idea. Still needs to be made by Horlander for Mac, Windows, and Linux.
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?
(Reporter)

Comment 9

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

Comment 10

8 years ago
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.
(Reporter)

Updated

8 years ago
Assignee: shorlander → faaborg
Priority: P2 → P1
Created attachment 485864 [details]
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.
(Reporter)

Comment 12

8 years ago
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.
(Reporter)

Updated

8 years ago
Assignee: faaborg → nobody
Assignee: nobody → anant

Comment 13

8 years ago
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

8 years ago
If a hidden expand or not preference is set, the group items may be expanded as a menu.
Duplicate of this bug: 609625
(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.
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.
Assignee: anant → raymond

Comment 18

8 years ago
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.
Status: NEW → ASSIGNED

Comment 19

8 years ago
(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.
Blocks: 606744
Created attachment 492329 [details] [diff] [review]
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
Attachment #491851 - Attachment is obsolete: true
Attachment #492329 - Flags: feedback?(ian)
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
Attachment #492329 - Flags: feedback?(ian) → feedback+

Comment 23

8 years ago
Is it necessary to separate App Tabs from the Active Group? I prefer Visible Tabs that "List all tabs" now shows.
Created attachment 493343 [details] [diff] [review]
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.
Attachment #492329 - Attachment is obsolete: true
Attachment #493343 - Flags: feedback?(ian)
Blocks: 614904

Comment 25

8 years ago
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 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?
This can wait until beta9, imo.
blocking2.0: beta8+ → beta9+
(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
(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.
Created attachment 494336 [details] [diff] [review]
V1

Removed the all tabs button
Attachment #493343 - Attachment is obsolete: true
Attachment #494336 - Flags: feedback?(ian)
Attachment #493343 - Flags: feedback?(ian)
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.
Attachment #494336 - Flags: feedback?(ian) → feedback-
Created attachment 494639 [details] [diff] [review]
v1

Removed the code for TabOpen.
Attachment #494336 - Attachment is obsolete: true
Attachment #494639 - Flags: feedback?(ian)
Comment on attachment 494639 [details] [diff] [review]
v1

Looks good to me.  I suggest Dao for review.
Attachment #494639 - Flags: feedback?(ian) → feedback+
(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

Updated

8 years ago
Blocks: 598154

Comment 35

8 years ago
Beta8 has 1 bug left on it, moving our blockers to b9
No longer blocks: 597043
Keywords: uiwanted
(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.
Keywords: uiwanted

Comment 37

8 years ago
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

8 years ago
(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

8 years ago
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

8 years ago
(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!
Drugoy, you should probably read this a few times: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 43

8 years ago
@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

8 years ago
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)
blocking2.0: beta9+ → betaN+
Another account disabled. Please report any further difficulties in the #bmo channel.

Gerv

Comment 50

8 years ago
(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.
(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.
Created attachment 501944 [details] [diff] [review]
v2

Based on the comment#36, use the default style of menu-button for the button.
Attachment #494639 - Attachment is obsolete: true
Attachment #501944 - Attachment is patch: true
Attachment #501944 - Attachment mime type: application/octet-stream → text/plain
Attachment #501944 - Flags: review?
Attachment #501944 - Flags: feedback?(ian)
(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 on attachment 501944 [details] [diff] [review]
v2

Looks fine as far as I can tell; assigning to Dao for review.
Attachment #501944 - Flags: review?(dao)
Attachment #501944 - Flags: review?
Attachment #501944 - Flags: feedback?(ian)
Attachment #501944 - Flags: feedback+
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.
Attachment #501944 - Flags: review?(dao) → review-
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

8 years ago
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.)
Created attachment 502428 [details] [diff] [review]
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.
Attachment #501944 - Attachment is obsolete: true
(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?
(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?
No, only that property isn't used.
Created attachment 502432 [details] [diff] [review]
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
Attachment #502428 - Attachment is obsolete: true
Attachment #502432 - Flags: review?(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 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.
Created attachment 502436 [details] [diff] [review]
v2

Updated the patch to remove browser.allTabs.previews in firefox.js and dropped the changes mentioned in #65
Attachment #502432 - Attachment is obsolete: true
Attachment #502436 - Flags: review?(dao)
Attachment #502432 - Flags: review?(dao)

Comment 67

8 years ago
bugspam (moving b9 to b10)
Blocks: 608028

Comment 68

8 years ago
bugspam (removing b9)
No longer blocks: 598154
Status: ASSIGNED → NEW
Whiteboard: [hardblocker]
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.
blocking2.0: betaN+ → -
Whiteboard: [hardblocker]
Target Milestone: --- → Future
(Reporter)

Comment 70

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

Comment 71

8 years ago
(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.
(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

8 years ago
(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.

Updated

8 years ago
Duplicate of this bug: 614904
(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.
Mockups don't fit with the new layout from Bug 597269
No longer blocks: 608028, 614904
(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
(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.

Updated

8 years ago
Blocks: 618791

Comment 79

8 years ago
Given the decision, would there be time to implement bug 618791 so we still ship with some tab management by default?
Attachment #502436 - Flags: review?(dao)
Duplicate of this bug: 644088

Updated

8 years ago
Duplicate of this bug: 644573
Do we still want to implement this?
Keywords: uiwanted
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

8 years ago
Created attachment 535007 [details]
Combined drop-down menu for the combined button

Comment 85

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

Comment 86

8 years ago
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

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

Comment 88

7 years ago
Oh my god, Aza. You are a real destroyer.
Leave 'list all tabs' button alone!
Assignee: raymond → limi
Keywords: uiwanted

Comment 89

7 years ago
This add-on also does something similar: https://addons.mozilla.org/en-us/firefox/addon/pano/
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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX

Updated

6 years ago
Assignee: limi → nobody
No longer blocks: 618791
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.