590483 - On closing Firefox when there are tabs hidden by Panorama, show Panorama before the prompt

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Panorama, defect, P3)

Description

[TGOS]

[Change summary if you feel like it, I just don't know how to express the issue in better words]

Consider the following case: I look at a Fx window on my screen, it has three tabs.

Does it show me, that those three tabs belong to a tab group? NO.

Does it show me, that other tab groups are existing? NO.

Does it show me, that altogether (all tab groups), there are much more tabs than the three ones I just see? NO.

So to me that is a window with just three tabs. That those belong to a tab group, that there are seven other tab groups and that there are altogether 50 tabs in all those groups is something I see where or how? Not at all, unless I go to manage the tab groups.

This means I close the window, get a warning, that I close open tabs, and the warning actually says 50 tabs, but I don't read it. I know that there are three open tabs and I think I get the warning because of those and it is okay if they are closed, so I just hit return on my keyboard. BOOM! 8 tab groups and 50 tabs gone for good. Can you understand the problem?

I miss a UI indicator that tells me:

1. The three tabs you see belong to the group "XXX".

2. There are YYY other groups for this window.

3. Altogether there are ZZZ tabs in YYY groups.

Without this, tab groups is an underground feature, not visible anywhere to anyone, unless you go to manage groups via menu or toolbar button.

Comment 1

[Dietrich Ayala (:dietrich)]

Yes, this is a real problem, especially for non-technical people who might not understand how they got to where they are.

Could need two UI elements here:

* one to go "back to normal". ie, show all tabs.

* one to zoom back out to Panorama.

I'd be surprised if this is not already filed, cc'ing the peeps who watch this component.

Comment 2

[collura]

this is lookling like a duplicate of bug#589010

neet toggle idea though

Comment 3

[custom.firefox.lady [:tawn]]

Same problem as Bug 590469 though I don't see any indication whatsoever, in the warning of how many tabs are open.

Comment 4

[Michael Yoshitaka Erlewine [:mitcho]]

Is this still as much of an issue now that bug 589010 has landed?

Comment 6

[antistress]

FWIW on Bug 597910 i've suggested to use the title bar : i.e. "25 tabs in 3 groups" could be display in the title bar

Comment 7

[Aza Raskin [:aza]]

Here's my proposed solution to this problem:

There are two cases:

CASE 1: There are tabs hidden by Panorama. That is, there is more than one group which in which each group has one or more tab.
CASE 2: The tabs you see are the only tabs that exists. I.e., Panorama isn't really being used.

In Case 1: where you are not currently in Panorama, when you try to close the window it should zoom out to the Panorama view and show you the "are you sure dialog". More than text, this gives you a visual and visceral overview of exactly what you are closing. If you click cancel it goes back to the tab you were at before.

In Case 2: No changes are necessary.

Comment 8

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

Yeah, I like comment 7.

Comment 9

[Nicolas Mandil (:NicolasWeb)]

(In reply to comment #7)
> Here's my proposed solution to this problem:
> 
> There are two cases:
> 
> CASE 1: There are tabs hidden by Panorama. That is, there is more than one
> group which in which each group has one or more tab.
> CASE 2: The tabs you see are the only tabs that exists. I.e., Panorama isn't
> really being used.
> 
> In Case 1: where you are not currently in Panorama, when you try to close the
> window it should zoom out to the Panorama view and show you the "are you sure
> dialog". More than text, this gives you a visual and visceral overview of
> exactly what you are closing. If you click cancel it goes back to the tab you
> were at before.

It should behave the same way if you close the last shown tab by the [x] on the tab (it's shown only when some tabs are hidden by Panorama). ;-)

Comment 10

[Aza Raskin [:aza]]

Yes, agreed.

Comment 11

[collura]

yes comment#7 sounds like a good plan

Comment 14

[Aza Raskin [:aza]]

Faaborg has brought it to our attention that:

>> This prompt is being removed over in bug 592822 in favor of always allowing
>> users to restore on open.

If this is the case, then we need know implementation change because the user can always restore...

Comment 15

[Raymond Lee [:raymondlee]]

Attachment: WIP v1

Waiting for the changes in Bug 592822.

The patch shows the Panorma UI on closing Firefox when some tab items exit but are not visible in the tabbar.

Comment 16

[Jose Fandos]

From comment 15 I understand that if there are hidden groups/tabs in Panorama, on closing window or last tab, you just get Panorama, correct? I.e. you don't get Panorama in the background with a modal window on top asking you to cancel/continue.

Just making sure, because the latter option, the one with the modal window with a question on top of a panorama window, has a terrible workflow.

Comment 17

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

>In Case 1: where you are not currently in Panorama, when you try to close the
>window it should zoom out to the Panorama view and show you the "are you sure
>dialog". More than text, this gives you a visual and visceral overview of
>exactly what you are closing. If you click cancel it goes back to the tab you
>were at before.

This works for right now, but I think the overall model here is wrong.  Anything that is explicitly user created (app tabs, tab groups, etc.) Shouldn't be linked to session restore and destroyed at the same time that the session is destroyed.  These are essentially bookmarks, and once the use says "remember this" we shouldn't keep asking "can I forget this now?"  We'll need cascading loading implemented before we can get this fully resolved, but ideally we should just close on close, and avoid deleting (either intentionally or unintentionally) information that the user actively organized in Firefox.

Comment 18

[custom.firefox.lady [:tawn]]

(In reply to comment #17)
> Anything that is explicitly user created (app tabs, tab groups, etc.) 
> Shouldn't be linked to session restore and destroyed at the same time that the > session is destroyed... 

True. It may be awhile since the user last had fx open (or used it on this machine); we shouldn't depend on them to remember whether they need the previous session restored (or that the session will still be available by the time they do remember). The alternative (for the user) would be to set the startup option to always "Show my windows and tabs from last time".

Comment 19

[antistress]

BTW the title of this bug report should expose the problem and not one solution, to let people discuss the best approach i think

Comment 20

[custom.firefox.lady [:tawn]]

If comment 17 's recommendation gets implemented, consideration should be taken not to keep (forever) reloading tab groups that a user might have created and forgotten about. Solution in comment 7 does make those hidden groups blatantly obvious. So neither solution is quite ideal by itself.

Comment 21

[Kevin Hanes]

bug spam (moving to b10)

Comment 22

[Kevin Hanes]

bug spam

Comment 23

[Michael Yoshitaka Erlewine [:mitcho]]

This would be great to have. Raymond, should someone else take over?

Comment 24

[Teoh Han Hui]

I always find it painful having to have all the previous tabs load (if I still want to work on them), when all I want to do is some quick browsing.

However, here's a use case to consider if the default ends up to be exiting without warning on clicking the close button:

The first time around:
1. The user has several tabs open that he wishes to continue working on.
2. The user needs to quit the browser.
3. Being accustomed to the previous behaviour, the user clicks on the close button expecting a warning.
3. The browser exits without prompting.
4. The user realizes the mistake and starts up the browser again.
5. The user manages to restore the previous session.
6. The user now has a false sense of security that the previous session can always be restored.

The second time:
1. The user has several tabs open that he wishes to continue working on.
2. The user needs to quit the browser.
3. The user clicks on the close button expecting the browser to exit without warning.
4. The browser exits without prompting.
5. The user needs to use the browser for some quick browsing.
6. The user starts up the browser.
7. The user doesn't want to deal with the previous tabs for now.
8. Assuming that the previous session can still be restored, the user quits the browser.
9. The next time the browser starts, the user tries to restore the desired session without any success.

I believe that is far from ideal. The idea of getting rid of unnecessary dialogs is great, but session restore needs to get improved if this were to work properly.

Comment 25

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

>Raymond, should someone else take over?

We're trying really hard to remove all interruptions on exist (for instance bug 592822) in favor of giving users control over restoring their data on start (bug 589665 and bug 593421).  So given all of the effort going in the direction of closing as soon as the user closes the window, I think this bug should be set to wontfix.

Comment 26

[Michael Yoshitaka Erlewine [:mitcho]]

Add bug 627251 to the consideration, too, which would also help specifically with the issue at hand here (even though we won't get to this one for fx4).

I agree and am marking wontfix.