576427 - Close all tabs in the TabCandy UI and the window disappears

Status: RESOLVED DUPLICATE of bug 613541

(Firefox Graveyard :: Panorama, defect, P3)

Description

[Ian Gilman [:iangilman]]

If you close the last tab in a window from within that tab, the window should close as it does. If, however, you close the last tab from within the TabCandy UI, you should still be sitting there in TabCandy. Currently, closing the last tab in the TabCandy UI does close the whole window.

Comment 1

[Raymond Lee [:raymondlee]]

Closing last tab from within TabCandy would mean no tab exists in that window. I see a problem that if there is no tab in a window, we can't show anything (not even a "blank" tab) when user quits TabCandy.

Comment 2

[Ian Gilman [:iangilman]]

What do you mean by quitting TabCandy? Do you mean zooming back in to a tab? It's true that shouldn't be allowed if there are no tabs to zoom back into.

Comment 3

[Aza Raskin [:aza]]

+1 to Ian's question.

Raymond:Once you close the last tab inside of the TabCandy interface, you cannot hide the TabCandy interface in that window (or in your terminology "quit TabCandy") because there are no tabs to zoom to.

Comment 4

[Raymond Lee [:raymondlee]]

I am able to show the close the last tab inside the TabCandy interface and the widow doesn't close.  However, some errors are thrown when I press the + button in the TabCandy interface.  The errors are related to  the content.document are not found since no tab exists.  The new tab is added to the right of the "+" button on the tabstrip instead of the left.  I am going to look into those issues.

Comment 5

[Raymond Lee [:raymondlee]]

Attachment: Patch

I have created a patch for this bug but there is still an issue.  Removing the last tab from a window and then adding some new tabs, all of the tabs show up on the right of the "new tab" button.  The patch uses the standard methods: tabbrowser.removeTab(tab) to remove the last tab, and the use tabbrowser.addTab(url) to add new tabs.  

There was a hack fixed the same issue in the "tabbrowser-tabs" binding, see
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#2492

However, it arises again when we remove last tab from the binding and add new tabs again.

@Aza/Ian: Is it possible to get some advices from someone who is familiar with binding code?

Comment 6

[Ian Gilman [:iangilman]]

Patch applied in: 

http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/3654c66d044e

Mardak, any ideas who to talk to about the remaining issue?

Comment 7

[Aza Raskin [:aza]]

Adding Paul to see if he has any insights into the problems described in comment 5.

Comment 8

[(no longer active)]

Mass moving all Tab Candy bugs from Mozilla Labs to Firefox::Tab Candy.  Filter the bugmail spam with "tabcandymassmove".

Comment 10

[alex_mayorga]

From bug 576427
Closing the only set actually close(s) the tab(s) AND Firefox.
Clearly a bug as I had "Warn me when closing multiple tabs" option
enabled but I wasn't warned at all.
Worst first use experience ever as there's not an obvious "mouseable" way to get out. Being vocal as this one really annoyed me when it bite me the first time =(

Comment 11

[[not reading bugmail]]

It would help if TabCandy was a secondary window, not replacing the main window.

Comment 12

[abittner]

it would help if closing (X for example on right upper corner of window/border or similar function in all of the different operating systems) the tabcandy outer window would result in simply going back where you came from, from the tabcandy-less view of the firefox window containing multiple tabs, and closing the grouped representation of the tabs inside the tabcandy view (the X functionality there) would result in a question if you were sure and would only continue there, etc....

when the resoning is that the tabcandy view takes over the main firefox window with/without multiple tabs open, and closing this window with the outer X of the window, then it should behave the same way as the original window.

behaviour of my firefox is, that it asks me if i was sure if i have more than a single tab open in that window, and it simply closes when i only have a single tab/area opened there.

thanks.
https://bugzilla.mozilla.org/show_bug.cgi?id=588355

Comment 14

[Aza Raskin [:aza]]

Raymond, can you confirm that this is still a bug (see comment #5).

Comment 15

[Raymond Lee [:raymondlee]]

(In reply to comment #14)
> Raymond, can you confirm that this is still a bug (see comment #5).

I recall that someone mentioned we are not allowed to remove the last tab in the browser and keep the browser open.  Therefore, the patch in comment #6 was backed out.  In other words, if you close all tabs in tab view UI, the browser would get closed.

Comment 16

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #15)
> (In reply to comment #14)
> > Raymond, can you confirm that this is still a bug (see comment #5).
> 
> I recall that someone mentioned we are not allowed to remove the last tab in
> the browser and keep the browser open.

Raymond, out of curiosity, was that a UX consideration or something necessary for us to pass tests?

Comment 17

[Raymond Lee [:raymondlee]]

(In reply to comment #16)
> Raymond, out of curiosity, was that a UX consideration or something necessary
> for us to pass tests?

It wasn't a UX consideration or something to do with tests.  It was about the architecture which supports browser window without a tab but I guess there must be something we can do to support that.

Comment 18

[Raymond Lee [:raymondlee]]

(In reply to comment #17)
> It wasn't a UX consideration or something to do with tests.  It was about the
> architecture which supports browser window without a tab but I guess there must
> be something we can do to support that.

Oops, I mean the architecture which doesn't support browser window without any tabs.

Comment 19

[Aza Raskin [:aza]]

Interesting. I could see how Firefox wouldn't support the case of a tab-less window. Sounds like something we'll have to fiddle with to get working right. Charge forth with the fiddling!

Comment 20

[Ian Gilman [:iangilman]]

This needs to be sorted out now that we have Panorama across all windows.  We're creating a UX where it's possible to load any tab into any window, but behind the scenes, each tab is hosted on a specific window at any one time.  This means it's possible that going into a group in one window will cause another window to close (if that other window had only the tabs for the group in question).  

We could possibly hack around it by moving tabs from other group or orphan tab to that window to keep it open, but even that won't work in some cases.  

We need to make it possible for a window to not contain any tabs.  If that occurs, that window needs to enter the tabcandy UI.

Comment 21

[Aza Raskin [:aza]]

Agreed. A Firefox window needs to be able to exist without any tabs (but only if it is in Tab Candy mode).

Comment 22

[Raymond Lee [:raymondlee]]

Who is the best person we can get some advices from about window without any tabs?

Comment 23

[Aza Raskin [:aza]]

Gavin, perhaps?

Comment 24

[Raymond Lee [:raymondlee]]

Gavin: please see comment #20 and comment #21

Comment 25

[Dão Gottwald [:dao]]

It's not clear what would break when a window has zero tabs, but it might be a lot. Not just within tabbrowser, but everything watching tabs could potentially break, add-ons as well as stock features like Aero Peek. TabCandy should probably make sure there's at least one group in each window; if there aren't enough groups left, it should in fact let the window close.

Comment 26

[Ian Gilman [:iangilman]]

(In reply to comment #25)
> It's not clear what would break when a window has zero tabs, but it might be a
> lot. Not just within tabbrowser, but everything watching tabs could potentially
> break, add-ons as well as stock features like Aero Peek. TabCandy should
> probably make sure there's at least one group in each window; if there aren't
> enough groups left, it should in fact let the window close.

Aza, what would you say from a UX perspective?  Seems weird that windows would arbitrarily close (from the user's perspective).  If we want this change, we should make it sooner than later to shake out the potential problems Dao mentions.

Comment 27

[Aza Raskin [:aza]]

Having a window close unexpectedly when clicking on a tab in another window's Panorama is confusing and scary. For that reason alone we should allow windows to have zero tabs.

A second and just as compelling reason is this: Imagine you have two windows A and B with groups a and b, respectively. You want to perform the simple operation of switching the to look at group b in window A, and group a in window B. You'd like to be able to go to Panorama in both windows and just click the group you want. If windows are not allowed to have zero tasks, however, this will fail in a strange and unexpected way. This is what will happen:

* In window A, you open Panorama.
* In window B, you open Panorama. (optional)
* In window A, you click on group b. Window B now closes.

Lastly, whether a window closes or not is dependent on the internal state of which window actually houses a tab. The user has no idea (and shouldn't have any idea) which tab is currently actually housed in which window. That is an implementation detail that shouldn't be exposed. But it is exposed when a window closes because no tabs are housed there, even if only temporarily.

Comment 28

[Aza Raskin [:aza]]

To give a sense of how wrong this feels, watch the following movie (http://people.mozilla.org/~araskin/panbugs/Closing.mov)

Comment 30

[Dietrich Ayala (:dietrich)]

Blocking+, for confusing and scary.

However, I don't understand why you're requiring zero tabs? Why not just use a new-window's default? (usually the user's home page, or about:blank). That shouldn't be overly surprising, since it's what a user sees anytime they open a new window.

Comment 31

[Tan Wei Lin Jason [:Ryuji]]

That would like forcing user to their home page or a blank page whenever they close all tabs in Tab Candy UI, which may not be what they want.

Comment 32

[Ian Gilman [:iangilman]]

The recent discussion in this bug has focused around the behavior in "all windows" (bug 578512). Now that that feature is getting bumped, we should refocus this discussion on what we're shipping with FF4 (or decide to bump this as well). 

Given how Panorama works now, closing the last tab and having the window go away is indeed jarring, but not nearly as much as shown in Aza's video; you'll never be in a situation where you close a tab in one window and have another window go away. 

What can still happen is you close all the tabs in a window (while in the Panorama UI), and the window goes away. Perhaps not what you expected, but pretty easy to understand what happened, and certainly no data loss. Not ideal perhaps, but livable.

Comment 33

[Aza Raskin [:aza]]

Ideally: Closing the last tab inside of Tab Candy shouldn't close the window. To implement this (WARNING: might be a terrible idea) we can upon closing the last tab open a hidden collapsed tab whose entire purpose is to give the window a tab so as to not close. The user would never see the hidden tab so this is entirely an implementation details.

Not-as-ideally: We let the window close when you close the last tab in Tab Candy. I would not mark this blocking.

Comment 34

[alex_mayorga]

Who knew the whole close Firefox when closing last tab bug 456405 would come and haunt us two years down the road.
I personally hated it back in the day, but somehow learned to live with it =)
Maybe bug 455852 can help here.

Comment 35

[Ginn Chen]

At least we should warn user, it is going to quit Firefox.
If I quit firefox with multiple tabs, I got a warning.
But if I close it in "Group you tabs ...", I got nothing.

Comment 36

[Ian Gilman [:iangilman]]

(In reply to comment #35)
> At least we should warn user, it is going to quit Firefox.
> If I quit firefox with multiple tabs, I got a warning.
> But if I close it in "Group you tabs ...", I got nothing.

That reminds me of another thing... with bug 587341 (undo close group), if you close the last group in Tab Candy (leaving no more tabs), your window will continue to exist for the next 15 seconds (while the "undo" button remains), but then the window will close (if you haven't made any new tabs in that time). Could be a little disconcerting.

Comment 37

[Aza Raskin [:aza]]

This is admittedly weird. That said, I don't think it is too weird. My preference, however, would be for for the last group's undo button to stay around indefinitely until the browser window is manually closed.

Comment 38

[Ian Gilman [:iangilman]]

(In reply to comment #37)
> This is admittedly weird. That said, I don't think it is too weird. My
> preference, however, would be for for the last group's undo button to stay
> around indefinitely until the browser window is manually closed.

That could be done! File a bug?

Comment 39

[Aza Raskin [:aza]]

File-up bug followed: http://bugzilla.mozilla.org/show_bug.cgi?id=595521

Comment 40

[Ian Gilman [:iangilman]]

This bug has been marked as "future" (post-ff4.0) but it still blocked our b8 milestone bug; removing blocking.

Comment 41

[TGOS]

> What can still happen is you close all the tabs in a window
> (while in the Panorama UI), and the window goes away. Perhaps
> not what you expected, but pretty easy to understand what
> happened, and certainly no data loss.

Right now there is a data loss: All my groups are gone! If I created 20 groups, took the hassle to name them all and layout them on my Panorama view (position and size) and then I close the last tab of the only group that still had one, it's all gone. All 20 groups are lost, their names and their layout.

If the window was still there, I could still create a new tab in one of the groups, surf around from there, spawning many new tabs, going back to Panorama view, moving some of the tabs to the already existing groups (with names and layout) and so on.

This is the main reason I'm currently not using Panorama at all. It's just too much hassle to name and/or layout groups, if I know those will be lost sooner or later anyway.