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

RESOLVED WONTFIX

Status

defect
P3
normal
RESOLVED WONTFIX
9 years ago
3 years ago

People

(Reporter: spamcop, Assigned: raymondlee)

Tracking

({ux-userfeedback})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [read comment 7])

Attachments

(1 attachment)

[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.
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.
Severity: enhancement → normal
OS: Mac OS X → All
Hardware: x86 → All
Summary: UI is not indicating existence of tab groups for current window → no visual indicator when the user is in a Panorama group
Version: unspecified → Trunk
this is lookling like a duplicate of bug#589010

neet toggle idea though
Same problem as Bug 590469 though I don't see any indication whatsoever, in the warning of how many tabs are open.
Is this still as much of an issue now that bug 589010 has landed?
Keywords: ux-feedback
Priority: -- → P4
Assignee: nobody → aza
Duplicate of this bug: 597910
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
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.
Summary: no visual indicator when the user is in a Panorama group → no visual indication that user is only seeing a subset of tabs can cause problems when closing a window
Blocks: 597043
Priority: P4 → P3
Target Milestone: --- → Firefox 4.0
(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). ;-)
Yes, agreed.
yes comment#7 sounds like a good plan
Assignee: aza → raymond
Status: NEW → ASSIGNED
Summary: no visual indication that user is only seeing a subset of tabs can cause problems when closing a window → On closing Firefox when there are tabs hidden by Panorama, show Panorama before the prompt
Whiteboard: [read comment 7]
Duplicate of this bug: 587245
Duplicate of this bug: 590469
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...
Posted patch WIP v1Splinter Review
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.
Attachment #479320 - Attachment is patch: true
Attachment #479320 - Attachment mime type: application/octet-stream → text/plain
Depends on: 592822
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.
Status: ASSIGNED → NEW
>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.
(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".
BTW the title of this bug report should expose the problem and not one solution, to let people discuss the best approach i think
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.
bug spam (moving to b10)
Blocks: 608028
bug spam
No longer blocks: 597043
This would be great to have. Raymond, should someone else take over?
Blocks: 627096
No longer blocks: 608028
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.
>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.
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.