485268 - Cannot close nor move first/leftmost tab (aka 3-pane tab)

Status: NEW

(Thunderbird :: Toolbars and Tabs, defect)

Description

[Michael C.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2

No matter how many folders or messages are open in tabs, the leftmost tab can not be closed.  Any other tab, whether it's a message or a folder, will close properly.

Reproducible: Always

Steps to Reproduce:
1. Open one or more messages or folders in a new tab (optional).
2. Click the red "X" on the right of the leftmost tab.
3. The tab will not close.
Actual Results:  
Any tab will close except the leftmost tab.

Expected Results:  
The leftmost tab should have closed, leaving the other tabs open.

Comment 1

[Phil Ringnalda (:philor)]

We used to let you close it, but with no way to reopen a 3pane that wasn't too pretty (by design, step 1 is not optional until we have a way to tell whether you have a 3pane open, and thus have a way to let you get back to one).

Bug 395388 will stop you from getting to step 2 by removing the close button, but that doesn't mean we shouldn't (eventually) either allow you to close the leftmost tab as long as you have another 3pane open, or allow you to close it because we have UI to let you reopen one.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

clarkbw, what is your suggestion for an optimal strategy here?  Various mix and match options I see are:

1) Add a little icon to the tab bar like lightning adds for its stuff to get a 3-pane back.
2) Never allow there to be "no" tabs.  When the user closes the last tab, open up a new 'blank' 3-pane tab.
3) Never allow there to be "no" 3-pane tabs.  When the last one gets closed, open a new one.
4) Allow there to be no visible tabs.  This ironically is a little bit of work because we need to add a display pane to be blank.

Comment 3

[Bryan Clark (DevTools PM) [:clarkbw]]

The question I'm confused by is 'what do our users really want to do here?'

If bug 395388 is  fixed and the close button gets removed from the first tab we'll start to remove the feeling that the first tab is 'closeable'.  I think there are other things we can do to make the first tab ( or at least the 3-pane tab type ) not look like a regular tab as well.

Of course this bug is about closing the first tab, but that's not an actual question or state that a persons grandmother would want to be in.  So the real user question as I see it is about some more advanced topic of having many tabs open.  

I'm just guessing from the tabbing research that has been done.  But I think from the mix of tab types that we have and the way that LTR readers tend to clean out their tabs that we could allow the first tab to be closed if there existed another tab of it's type ( 3-pane ) around.

> 1) Add a little icon to the tab bar like lightning adds for its stuff to get a
> 3-pane back.

I'd like to add the (+) new tab button and with a decent new tab page design users should be able to get to the 3-pane quickly from that page.

> 2) Never allow there to be "no" tabs.  When the user closes the last tab, open
> up a new 'blank' 3-pane tab.

I don't really like the 'popup a new tab' approach, it's a somewhat dangerous path to cross when you reopen something the user just closed.  If they don't understand why you've reopened it the game doesn't seem like fun.

> 3) Never allow there to be "no" 3-pane tabs.  When the last one gets closed,
> open a new one.

I like this one, except for the popup approach like above.  I think if the last tab of 3-pane type wasn't closeable we would have a very similar approach that works just as well.

So the first tab would become closeable once a new 3-pane tab was in the mix. And once the last 3-pane tab was standing it wouldn't be closeable.

> 4) Allow there to be no visible tabs.  This ironically is a little bit of work
> because we need to add a display pane to be blank.

I'm not really sure what you mean by this one.  Is this removing tab bar titles?


I want to keep the 3-pane tab around because it seems like a really difficult path to allow it to be closed; and then have created ways for people to get back to it.  I'm still open to that approach, but I think it takes a lot more work to make it happen in a clean way that won't leave us with worse situations than this.

Comment 5

[Richard Mlynarik]

(In reply to comment #3)
> The question I'm confused by is 'what do our users really want to do here?'

I see *no problem* with either of these situations:

1. The last tab is closed and Thunderbird has no windows.  People deal with this in browsers *all the time*.

2. The last 3-pane tab is closed and Thunderbird only has tabs displaying messages.  People make or recreate new windows and tabs in other programs all the time.

The solution is the same in both cases: either
(a) add a simple command under the File / New ... menu to create a new mailbox displaying tab (creating a new window in the process if necessary); or
(b) add a simple "+" control to the existing tab bar, EXACTLY LIKE that in existing web browser tab bars, that make a new 3-pane tab.

Right now the whole TB tab thing is just oddly inconsistent and half baked, and not just with this one bug.  (And yes, thanks for the tens of thousands of
*volunteer* hours which have produced what we have today, OK!!!)

I know it took a long time for Firefox to get where it is, but I think it's
a good model to emulate (don't invent new UI, and do try to be consistent),
especially for things TB can't do yet but should, like have multiple windows,
move tabs between windows, rearrange the order of tabs, move an existing tab
into a new window, etc.

A larger feature request I know, but people wouldn't report this one small
bug if things didn't work The Way We've Been Taught To Expect Them To Work,
so anything that's been done ought to be done in that direction.  There are
a zillion more tabbed browser users around than TB users, after all, from
both the evangelism and the unexpected behaviour perspectives.

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: UI Mockup - v1

I'd like to see this bug fixed, this way the way is paved for Thunderbird+Lightning to be either Mail, Calendar or both, depending on what kinds of accounts the user has created.

The idea I wanted to throw in, is when all tabs are closed, that a tab is showing something similar to the current accountCentral area opens. I think that this in addition to the previously suggested (+) new tab pane would fit in quite good. Clicking on links like "Read messages" should open the 3pane too.

I've attached a mockup of what I could imagine Thunderbird+Lightning looking like at first startup, i.e no accounts are created. Its only marginally related to the bug, I just wanted to demo how a first non-3pane could look like. The content is obviously subject to change though.

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I just found bug 477652, which could also be something to show when the last tab is closed.

Comment 8

[Mark Banner (:standard8)]

Note: I'm not sure this bug is just about providing a UI for when the left-most tab is closed, iirc the UI code makes some big assumptions about always having a three-pane open (unfortunately I can't remember the specifics).

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to comment #8)
> Note: I'm not sure this bug is just about providing a UI for when the left-most
> tab is closed, iirc the UI code makes some big assumptions about always having
> a three-pane open (unfortunately I can't remember the specifics).

but would this happen if the main pane were open, but not folder pane?

bienvenu understands this area iirc. And some recent examples of complications from main UI being closed:
* Bug 530779 - With main window/3-pane closed, sent email cannot be copied to "sent"-folder and drafts cannot be saved - "There was an error copying the message to the Sent folder. Retry?"
* Bug 560745 - Let the migration assistant still work if the 3-pane window's closed

Comment 10

[Bryan Clark (DevTools PM) [:clarkbw]]

Attachment: home app tab

I chatted with several people about this concept which I believe is similar to what Philipp is proposing.  Firefox, for the FF5 release is considering creating a similar type of "home tab" system as well.

The mockup shows an "app tab" tab which is the "home tab".  This tab is the only one that always needs to exist in a Thunderbird window.  The tab would likely show similar content to what Philipp had in it with links to open up your Inbox or add-ons.  This way we could always have one tab open and it wouldn't have to be the 3 pane tab.  As Mark points out though there would need to be a lot of investigation if this was possible because TB relies on the 3 pane being available.

Other possible improvements that come along with this is that we could remove the stand alone window code and instead open up messages in a new window using the same window with a single "home app tab" and then the message tab.

Comment 12

[Thomas Schmid]

Attachment: Mockup

A slightly different approach.

Behaves like the "quick filter bar". It adds a special tab which toggles the tree view pane. The extension attached is a quick mockup to illustrate this.

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 546368 [details]
Mockup

(Blake Winton is Thunderbird's UX lead now.)

It's fantastic that you provided an extension to demonstrate your idea!  Could you elaborate on the idea a bit more and how it helps address this bug?  (Screenshots are also always nice when possible.)

Specifically, from looking at the source, I can see that you are adding a toggle button to the tab bar whose state is maintained on a per-tab basis.  The button causes the #folderPaneBox and #displayDeck to be collapsed, leaving only the message pane visible.

I am not clear on how this relates to the inability to close the leftmost 3-pane tab or the ability to get it back.  Are you proposing creating a orthogonal setup, sort-of like the sidebar mechanism supported by various Mozilla web-browsers, where you always have the ability to make a 3-pane appear at any time (and which temporarily occludes whatever tabs are being displayed)?

Comment 14

[Thomas Schmid]

(In reply to comment #13)
> Comment on attachment 546368 [details]
> It's fantastic that you provided an extension to demonstrate your idea! 
> Could you elaborate on the idea a bit more and how it helps address this
> bug?  (Screenshots are also always nice when possible.)
>
> 
> Specifically, from looking at the source, I can see that you are adding a
> toggle button to the tab bar whose state is maintained on a per-tab basis. 
> The button causes the #folderPaneBox and #displayDeck to be collapsed,
> leaving only the message pane visible.
> 
> I am not clear on how this relates to the inability to close the leftmost
> 3-pane tab or the ability to get it back.  Are you proposing creating a
> orthogonal setup, sort-of like the sidebar mechanism supported by various
> Mozilla web-browsers, where you always have the ability to make a 3-pane
> appear at any time (and which temporarily occludes whatever tabs are being
> displayed)?

As far as I know closing the left most tab is disabled, because it could happen, that you end up having no treeview or message pane and there is no way to get it back. As illustrated in the screenshot attached. With such a toggle button, you could get the treeview /message view back in such situations. So there would be no need to disable the close button. So you are right, this mechanism would act like some kind of a sidebar.

The toggle status is maintained on a per tab basis. So you end up with a fast way to switch messages to fullscreen an back. Try the following, select a message in the folder pane, then click on the toggle button. The message gets converted to "fullscreen", to get back to the folder pane just click again. So there would be no need for having a separate "messagewindow.xul".

Furthermore you could merge the "mailContent" and "message" tabs mode as they would be same. So the code base could get easier and cleaner. Which would be a huge step towards fixing Bug 537677.

I've optimized the mockup so that it works more reliable now.

Comment 15

[Thomas Schmid]

Attachment: Updated Mockup

Comment 16

[Thomas Schmid]

Attachment: Mockup, beeing standed with a message window

Comment 17

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #14)
> As far as I know closing the left most tab is disabled, because it could
> happen, that you end up having no treeview or message pane and there is no
> way to get it back. As illustrated in the screenshot attached. With such a
> toggle button, you could get the treeview /message view back in such
> situations. So there would be no need to disable the close button. So you
> are right, this mechanism would act like some kind of a sidebar.

It seems like you are assuming the only types of tabs we have are (what the code knows as) "folder" and "message" tabs.  Assuming that if the mockup were implemented we would make the leftmost 3-pane closable, what happens when all that is left is a (web) content tab or a lightning tab?
 
> The toggle status is maintained on a per tab basis. So you end up with a
> fast way to switch messages to fullscreen an back. Try the following, select
> a message in the folder pane, then click on the toggle button. The message
> gets converted to "fullscreen", to get back to the folder pane just click
> again. So there would be no need for having a separate "messagewindow.xul".

I'm not sure I follow; it seems like the standalone message window is a separate issue given that we already have a tab that displays just message contents.  (And I believe there is already a bug on replacing it with a standard messenger.xul window using our existing "message" tab functionality.)

It also seems like the ability to ability to transition a "message" tab to a "folder" tab is a separate enhancement request.  (And a potentially dangerous one at that; having a button users can accidentally click that hides the folder pane and thread pane seems more likely to do harm than good.)

> Furthermore you could merge the "mailContent" and "message" tabs mode as
> they would be same. So the code base could get easier and cleaner. Which
> would be a huge step towards fixing Bug 537677.

The logic behind both tab types is already the same code with very minor subclassing where tab behaviour differs (versus adding additional conditionals in a single class).  What you are proposing is more likely to increase complexity because we would need to also handle the transition state between folder tabs and message tabs.

There is notable complexity there because of situations such as where the thread pane is operating in threaded mode with a collapsed thread displayed and the thread summary is displayed in the message pane.  It is currently not a legal state for the message tab to display the thread summary, and it's not clear what happens to the thread pane's 'threaded' state when you transition to message-only display and back again.  Since message tabs still maintain an nsMsgDBView under the covers to allow 'f'orward and'b'ackward operations to occur, it's a real issue.  And all of these transitions would need to have unit tests.

Comment 18

[Thomas Schmid]

(In reply to comment #17)
> (In reply to comment #14)
> It seems like you are assuming the only types of tabs we have are (what the
> code knows as) "folder" and "message" tabs.  Assuming that if the mockup
> were implemented we would make the leftmost 3-pane closable, what happens
> when all that is left is a (web) content tab or a lightning tab?

Nope, that's not true ;-) But as it was intended to be just a mockup/proposal I skipped that part to reduce complexity. In case if you have content tab etc. , a click on the toggle would open up a folder plane. As it was a one liner to implement that, I've updated the attachment. Just give it a try.

> It also seems like the ability to ability to transition a "message" tab to a
> "folder" tab is a separate enhancement request.  (And a potentially
> dangerous one at that; having a button users can accidentally click that
> hides the folder pane and thread pane seems more likely to do harm than
> good.)

assume only one tab is open and a user clicks accidentally on the toggle button, he will endup with  a message view. Which is not dangerous at all. It's like opening a message via "open message in new window" and then accidentally closing the parent window. In either case closing the window will result in termination Thunderbird. But when restarting Thunderbird the issue is resolved automatically, as the very first tab always shows a folder view...

> The logic behind both tab types is already the same code with very minor
> subclassing where tab behaviour differs (versus adding additional
> conditionals in a single class).  What you are proposing is more likely to
> increase complexity because we would need to also handle the transition
> state between folder tabs and message tabs.
> 
> There is notable complexity there because of situations such as where the
> thread pane is operating in threaded mode with a collapsed thread displayed
> and the thread summary is displayed in the message pane.  It is currently
> not a legal state for the message tab to display the thread summary, and
> it's not clear what happens to the thread pane's 'threaded' state when you
> transition to message-only display and back again.  Since message tabs still
> maintain an nsMsgDBView under the covers to allow 'f'orward and'b'ackward
> operations to occur, it's a real issue.  And all of these transitions would
> need to have unit tests.

Well, I have the feeling you are thinking too complicated. I thought about getting rid of the "message" tab having only a "folder" tab, with the option toggle/hide the folder view. So there should and can't be any major issues, as the message view does not offer any functionality that folder view does not. If there would be any issues, the "folder" would currently suffer from then. As you wrote "the logic behind both tabs is already same". So it's just about hiding two panes, so that you can get rid of one tab mode. 

So I actually can't follow you example on back/forward. Just select a thread summary in the folder view. Then hit the back button and the thread's previous message will be displayed, if you hit the forward key, you end up at the thread's next message. So this "strange" behaviour is accepted by users, at least i did not find any bugs about this.

Comment 19

[Jim Porter (:squib)]

(In reply to comment #18)
> assume only one tab is open and a user clicks accidentally on the toggle
> button, he will endup with  a message view. Which is not dangerous at all.

It's not destructive, but it's certainly a confusing (or at least non-standard) UI. Bear in mind, people are already confused about the folder view selector at the top of the folder pane because it's non-standard. We shouldn't be creating UIs that don't have precedent elsewhere unless we have a very good reason why no already-established UI would work.

In this case, I'm fairly certain an established UI would be just fine, since all we need is some way to open up a 3pane if it gets closed. There are at least a couple ways to do that: 1) add a tab bar button a la Lightning, 2) add a "home tab" that lets you open up other important tabs (3pane, calendar, etc). I think sid0 is experimenting with (2) now.

> It's like opening a message via "open message in new window" and then
> accidentally closing the parent window. In either case closing the window
> will result in termination Thunderbird. But when restarting Thunderbird the
> issue is resolved automatically, as the very first tab always shows a folder
> view...

With session restore, that wouldn't happen, and I don't think it makes sense to disable session restore for this case. We certainly shouldn't be disabling session restore to work around a confusing UI; we should just make the UI obvious in the first place.

This proposal works fine as an add-on, since users have to take the initiative to install it (and hopefully read at least a few sentences about it), but I think we should be very careful about adding UI that doesn't have a clear precedent in other UIs to Thunderbird itself. Every time we do that, we're forcing people to think about what they're trying to do, rather than just doing it. That should be avoided whenever possible: no one should be required to think about their email *client* rather than their emails.

Comment 20

[Lewis Rosenthal]

I bumped into this while exploring the possibility of developing an extension to open a calendar window separate from MailNews in SeaMonkey, along with the "old style" status bar icon in the browser and MailNews windows. I thought I might work around some issues by just opening another mail window with the calendar by itself. Testing for look and feel, I found that I couldn't close the leftmost tab, which led me here. :-)

I tried out Thomas' extension, after some minor tailoring for SM, and I agree with Jim's comment 19 that this does pose an issue for the UI (it's fine as a workaround, but not a real solution to the problem).

Considering the last comment here was almost a year ago, I'm wondering if anyone has put any further thought into this?

Meanwhile, although the tab is not closeable, right-clicking it (in SM, at least; haven't tried TB), brings up the expected context menu with the single entry to close the tab, which is confusing by itself.

Comment 25

[Peter]

Thank you very much for providing a way to use Thunderbird without setting up an email account. (See bug 942615.)

Please also provide a way to close the now blank first (email) tab, the topic of this bug.

My use case is to only use the calendar in Thunderbird, and that's possible. But it's only the second tab in Thunderbird, and I can't move the calendar tab to the first position. Nor can I close the first tab, which is the email/feed tab.

Comment 27

[Magnus Melin [:mkmelin]]

Geoff, maybe this would be fairly feasible now?