Closed Bug 508776 Opened 15 years ago Closed 12 years ago

Close tab should return to last tab, the tab in view prior to the one being closed, not just go to the adjacent tab when closing message (close, go to previous / use z-order)

Categories

(Thunderbird :: Toolbars and Tabs, defect)

defect
Not set
normal

Tracking

(blocking-thunderbird5.0 -)

RESOLVED FIXED
Thunderbird 15.0
Tracking Status
blocking-thunderbird5.0 --- -

People

(Reporter: vincenzo.dandrea, Assigned: mconley)

References

()

Details

(Keywords: helpwanted, ux-efficiency, Whiteboard: [gs][UXprio][firefox-parity][mentor=mconley][lang=js|xbl])

Attachments

(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.13) Gecko/2009073021 Firefox/3.0.13
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3

I have selected the "Open message in a new tab" option.
I have several tabs open at the same time.
I open a message by double clicking on it. The message is opened in a new tab, placed to the right of the rightmost one.
When I close the message, the active tab is now the one to the left of the one being closed - that is the one which was previously the rightmost one.
The desired behavior (similar to how Firefox deals with tabs) would be to re-activate the tab which was active before opening the message - in other word go back to the folder ...

Reproducible: Always

Steps to Reproduce:
1. select the "Open message in a new tab" option.
2. open several tabs
3. activate Inbox (or any folder)
4. open a message by double clicking on it
(The message is opened in a new tab)
5. close the message
Actual Results:  
The active tab is now the one to the left of the one just closed - that is the one which was previously the rightmost one.

Expected Results:  
The desired behavior (similar to how Firefox deals with tabs) would be to re-activate the tab which was active before opening the message - in other word go back to the folder ...
Confirming as an enhancement to the current implementation.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-thunderbird3+
OS: Mac OS X → All
Hardware: x86 → All
Summary: When closing a "New message" tab focus goes to the adiacent tab instead of the most recent → When closing a "New message" tab focus goes to the adjacent tab instead of the most recent (close, previous)
Hi Sid:

At today's Get Satisfaction Meeting, it was suggested by Bryan Clark and Ludo that you might have time to fix this either in 3.1 or 3.1.next? 

Sid: please take this bug if you have time to fix it.
Whiteboard: [gs] → [gs][UXprio]
Hmm, this might need to be a user preference. If I'm opening a bunch of tabs to read later, then I'll want to read them all at once, and not go back to 3-pane..

I can see a need for this though if I'm not reading messages like I just mentioned. Perhaps a quicker method of toggling this pref back and forth somehow??
(In reply to comment #5)
> Hmm, this might need to be a user preference. If I'm opening a bunch of tabs to
> read later, then I'll want to read them all at once, and not go back to
> 3-pane..
(In reply to comment #5)
> Hmm, this might need to be a user preference. If I'm opening a bunch of tabs to
> read later, then I'll want to read them all at once, and not go back to
> 3-pane..

I usually read one message per time, sometimes two, rarely 3, never more. I'd like TB to go back to "Mail" tab when I close a message (I have Lightning, and it always goes to "Tasks" tab).

> I can see a need for this though if I'm not reading messages like I just
> mentioned. Perhaps a quicker method of toggling this pref back and forth
> somehow??

IMHO, great. I vote for previously accessed tab as default :) .
It is a great feature in Firefox 3.6.8.
Why is it not renewed under thuinderbird 3.x??

I vote for its use.
Of all the tabs bugs, I think this is the most annoying, and problematic for good workflow in tabs - plus it's listed on UX/Prio wiki. And it will get more annoying as more functions are driven into tabs. So nominating blocking 3.3. I.E. it would be super duper to get this.

perhaps bug 545552 comes in second, or equal.
Blocks: tabsmeta
Severity: enhancement → normal
blocking-thunderbird5.0: --- → ?
Keywords: ux-efficiency
Summary: When closing a "New message" tab focus goes to the adjacent tab instead of the most recent (close, previous) → Return to tab in view when the one being closed was spawned, eg when closing a "New message" tab focus should not go to the adjacent tab (close, previous)
Whiteboard: [gs][UXprio] → [gs][UXprio][firefox-parity]
Yeah, so, the current behavior has made me really rethink my use of Thunderbird.  While I appreciate that it's open source, this really is a pretty absurd thing to overlook.

OK, this Bug List INC has been out there for almost a year and a half.  It doesn't sound like much of problem to program, and it would be really nice to have.  Could we get someone to step up and knock this out?  I know that I'd be most thankful, as it would seem several other folks would be.

Thanks in advance to you all for your time!
With two updates in the last week, you'd think someone would have addressed this annoyance by now?
(In reply to comment #12)
> Yeah, so, the current behavior has made me really rethink my use of
> Thunderbird.  While I appreciate that it's open source, this really is a pretty
> absurd thing to overlook.
> 
> OK, this Bug List INC has been out there for almost a year and a half.  It
> doesn't sound like much of problem to program, and it would be really nice to
> have.  Could we get someone to step up and knock this out?  I know that I'd be
> most thankful, as it would seem several other folks would be.
> 
> Thanks in advance to you all for your time!

(In reply to comment #13)
> With two updates in the last week, you'd think someone would have addressed
> this annoyance by now?

politeness does not remove the need to observe etiquette. experienced bugzilla-ers would not make such comments. please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
(In reply to comment #14)
 
> politeness does not remove the need to observe etiquette. experienced
> bugzilla-ers would not make such comments. please read
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

My most ardent apologies - As someone new to the list, I did not read the etiquette rules beforehand.  I have now voted for this bug, which should have been my first (and only) action.
This may feel like just an enhancement for those reading emails, but when using Lightning it's more annoying - ending up in the irrelevant Calendar tab all the time actually feels more like a bug.

This is an important annoyance to fix, you have my vote.
We wouldn't block releasing 3.3 on this. Setting to helpwanted as we would like and will accept patches on it.
Severity: normal → enhancement
blocking-thunderbird5.0: ? → -
Flags: wanted-thunderbird+
Keywords: helpwanted
Summary: Return to tab in view when the one being closed was spawned, eg when closing a "New message" tab focus should not go to the adjacent tab (close, previous) → Close tab should return to last tab, the tab in view prior to spawning the one being closed, not just go to the adjacent tab when closing message (close, previous)
FWIW, the recently changed summary is somewhat misleading:

"Close tab should return to last tab, the tab in view prior to spawning the one being closed, not just go to the adjacent tab when closing message (close, previous)"

It should only return to that tab IF no other tab has been in view since it was spawned. At least if it is meant to have the same behaviour as Firefox tabs, and if it is meant to be well-behaving. :-)

(This might be more or less obvious, but programmers have made mistakes before)
thanks mr. yes, i actually buggered it a couple months ago
Summary: Close tab should return to last tab, the tab in view prior to spawning the one being closed, not just go to the adjacent tab when closing message (close, previous) → Close tab should return to last tab, the tab in view prior to viewing the one being closed, not just go to the adjacent tab when closing message (close, previous)
Now it got at least as misleading as before, I think... :-)

"Close tab should return to last tab, the tab in view prior to viewing the one being closed, not just go to the adjacent tab when closing message (close, previous)"

I'd suggest a summary like this:

"If a new tab was spawned, shown, and then closed without any other tab being in view during its life, then the view should return to the tab that spawned it."
I think that the best way to express this bug is:

Tabs should work (regardless of theyr order in the tab bar) just as a stack of paper sheets: every time a tab gets in view, it should be put on top of the stack, so that discarding tabs results in showing tabs in order of last visit.
(In reply to comment #25)
> I think that the best way to express this bug is:
> 
> Tabs should work (regardless of theyr order in the tab bar) just as a stack
> of paper sheets: every time a tab gets in view, it should be put on top of
> the stack, so that discarding tabs results in showing tabs in order of last
> visit.

Hmmm... only if you keep re-ordering papers in the middle of the stack according to ordinary tab customs, I guess. And I've never seen a paper stack like that. :-)

Consider 3 tabs: 1, 2, 3.

Show 1.
Then show 2.
Then close 2. Now 3 is shown, regardless of what tab was shown before. Not 1.
really, i think the gist of this issue is well understood, and all we need is a patch. thanks.
Severity: enhancement → minor
I'm not so sure that the gist of the issue is well understood. Now that TB 5.0 is out, this issue persists.
While you can now reorder some tabs, the Lightning and Inbox Tabs cannot be, and there is no other means of preferring tab focus direction.

Perhaps this is just too difficult to accomplish.
The fact that the issue persists doesn't mean that it isn't well understood. Please, no more comments unless you have a patch.
My understanding is that this affects every user all day long, so shouldn't it be flagged at a higher priority than "minor"? Thanks
(As for the expected behavior, comment 25 seems to be quite natural)
agree, difficult when there are many tabs. but changing severity won't help it get fixed faster :)

BTW, severity <> development priority. Severity is a measure of impact on a single individual. see https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity
Severity: minor → normal
Summary: Close tab should return to last tab, the tab in view prior to viewing the one being closed, not just go to the adjacent tab when closing message (close, previous) → Close tab should return to last tab, the tab in view prior to the one being closed, not just go to the adjacent tab when closing message (close, go to previous / use z-order)
The current behavior in Firefox 7.0.1 seems to be this:
1. There is a global property of the browser window which stores either the owner, ownerTab or "related tab" (at least as specified in addTab) of the current tab, but this is reset to nothing every time the current tab changes. This is used to determine which tab would be focused when the current tab closes.
2. If the above property is nothing, then the focus switches to the tab on the right.

In my opinion, there are four ways this can be "fixed":
1. Always switch to the tab on the *left*.
2. Switch to the last viewed tab, based on the order in the ctrlTab previews.
3. For every tab, there can be an owner. (At least that's what browser.addTab has as one of the parameters.) If there isn't any owner, switch to the last opened (not viewed) tab.
4. Assuming the owner relationships form a tree ordered by opening order, switch to the last tab in the subtree rooted at that point*, or if there is none, switch to that of the parent tab.
  * - you recursively take the last sibling if it exists.

I prefer the second solution.
For (2), another way is to switch to the last opened tab as mentioned in (3).
For (4), I meant "last child" nor last sibling.
The order determining (3) and (4) can be last opened or last viewed. Or maybe it should be a separate option, i.e. to order tabs by opening time or last-viewed time. Also, opening time (and last opened) can be interpreted as time of page load (last navigated) instead.

Google Chrome also has a weird behavior. It seems there is also a global property that stores a tree structure, but every time you go to a new tab, it must be an immediate sibling, parent or child of the tab you came from, if not the whole tree is destroyed. If the tree has been destroyed, closing a tab would focus on the tab on its right. Otherwise it uses this priority:
1. Immediate children on its right, then left
2. Immediate siblings on its right, then left
3. Immediate parent
Not sure whether this is really correct though.
(This can be done in concert with the tabs-on-top work, right Mike?)
Assignee: nobody → mconley
It could, yes, seeing as how I kind of have an idea of how tabmail works now.  We just need to decide on an algorithm.  Did you have a preference?
Depends on: tb-tabsontop
Attached patch Patch v1 (obsolete) — Splinter Review
Here's my first run at a patch.  I'll write some Mozmill tests next.
I've got a tabs-on-top build with this patch building on try right now - installers should be available in a few hours at:  http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/mconley@mozilla.com-1b6eedda6ea5
I'm striking out all over the place

my first startup, installed from windows .exe file, crrashed @ PR_JoinThread
bp-b1403a66-cf5f-47ab-b6f7-5152a2111129

ctrl+tab, ctrl+shift+tab don't meander through tabs

closing current tab isn't going back to most recently used tab

I miss having global search available on every tab
I may be wrong, but shouldn't this.mLastTabOpener be tested first by an if() before using it with indexOf? And shouldn't the selectedIndex be set directly to lastTabOpenerIndex instead of indexing it again?

On a side note, the patch looks to me to be the current behavior in Firefox, but I thought we were going to use the last-viewed tab?
I just found out that Tab Mix Plus has this functionality already, under "Events > Tab Closing > Closing Current Tab". Maybe the best option from there could be built into Firefox as default.
Thank you to all who are finally trying find a solution to this reeaaally annoying bug.

As an early reporter of this bug however, I'd like to point out that this is a Thunderbird issue. Firefox is already well behaved.

The essence is that with several tabs open in TB, close any one tab and the focus goes to the right most open tab. This is especially annoying to those using Lightning because with just one email message tab open, when you close it the focus always goes to the Calendar tab. Another click is always required to get back to the mail tab.
I'd like to add another note: since TB does NOT stack tabs in rows as FF does, but instead scrolls them to the right and the left, this bug gets specially annoying, since the tab that gets put in focus might as well be one that... is INVISIBLE at the moment!
Hi all,
2 years, 7 months since first reported. Now Tabs on Top seems to increase the annoy factor. Is anyone working on a resolution for this?

Does the patch that Mike Conley posted work? If so, can someone explain how to apply it?
Thanks
Whiteboard: [gs][UXprio][firefox-parity] → [gs][UXprio][firefox-parity][mentor=mconley][lang=js|xbl]
Ok all - I think I've got some cycles to work on this again.

I've created a try build with this patch.  Please test this out and tell me if I've missed something wrt tab closing behaviours:

Builds for each platform are here:
https://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/mconley@mozilla.com-d5542148f7ea/

Thanks,

-Mike
I tryed it and except from beeing very slow, I don't see different to TB 11 behaviour.

I opened 3 emails, returned to main tab (folders list), opened last of 3 email tabs, closed it.
I think expected behaviour should be to return to main tab after close, but it just opened first email tab on the left.

Tested windows version, last file in windows folder called thunderbird-14.0a1.en-US.win32.zip
Tested the same build as Stanic, but for me it worked like a charm: the tabs ope and close and get in view scrolling the tab bar as expeted, and finally tabs do work as they always should have worked!
Is the try-comm-central-macosx64/ what I need for Win7 64bit?
Never mind that last - I realized just as I hit "Save Changes" that macos means Mac OS...  <dunce cap>
Attached patch Patch v2 with tests (obsolete) — Splinter Review
This patch fixes the case where multiple messages are opened simultaneously (by double-clicking on a thread header, for example).  In that case, we don't remember the tab opener, so closing the last message tab goes to the second-last message tab, etc.

Again, that only applies if opening a series of message tabs all at once.  If we open a single message tab from the inbox tab and close it immediately, we still go back to the inbox tab.

Blake:  what do you think?
Attachment #577366 - Attachment is obsolete: true
Attachment #618352 - Flags: ui-review?(bwinton)
Comment on attachment 618352 [details] [diff] [review]
Patch v2 with tests

So, (as mentioned in person) I think that we should still group tabs opened by a single ui action, and when all of those are closed we should return to the calling tab.  But this seems like enough of a step forward to land by itself, so I'm going to say ui-r=me, and hope that we can implement the improvements sometime soon.

Thanks,
Blake.
Attachment #618352 - Flags: ui-review?(bwinton) → ui-review+
Attachment #618352 - Flags: review?(squibblyflabbetydoo)
Whoops - looks like my tests broke the test-tabmail-dragndrop.js tests when running the tabmail directory.  That's because my testing folder was given the same name as the one in test-tabmail-dragndrop.js.

I've switched the name, and the tests all pass.
Attachment #618352 - Attachment is obsolete: true
Attachment #618406 - Flags: review?(squibblyflabbetydoo)
Attachment #618352 - Flags: review?(squibblyflabbetydoo)
Works great! Thanks for making these improvements. Hope to see this implemented in an upcoming release for TB
Comment on attachment 618406 [details] [diff] [review]
Patch v3 (carrying over ui-r+ from bwinton)

Review of attachment 618406 [details] [diff] [review]:
-----------------------------------------------------------------

Modulo my comments in IRC (reformat the comment block explaining the arguments to openTab), this looks good to me. I've confirmed that the tests pass, and that the behavior is as expected.
Attachment #618406 - Flags: review?(squibblyflabbetydoo) → review+
Would someone please advise as to which package I should download for Win7?
(In reply to Blane Robertson from comment #54)
> Would someone please advise as to which package I should download for Win7?

Hey Blaine,

Sure - try this file:  https://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/mconley@mozilla.com-d5542148f7ea/try-comm-central-win32/thunderbird-14.0a1.en-US.win32.installer.exe

-Mike
Fixed the formatting in the tabmail documentation as requested in squib's review.
Attachment #618406 - Attachment is obsolete: true
Landed in comm-central as http://hg.mozilla.org/comm-central/rev/49bc6cc53129

\o/
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 15.0
Is there any particular reason why Firefox doesn't do this as well (defaults to adjacent tab on close)?
I'm still having this problem with 15.0.1, is there an open bug report I should mention this on?

I'm also having an issue with it opening two tabs for the same link (which was briefly mentioned in the comments here).

If you need more info, let me know.
(In reply to agorilla from comment #59)
> I'm still having this problem with 15.0.1, is there an open bug report I
> should mention this on?
> 
> I'm also having an issue with it opening two tabs for the same link (which
> was briefly mentioned in the comments here).
> 
> If you need more info, let me know.

Hello agorilla,

If you wouldn't mind filing a new bug and writing in some steps to reproduce the issue you're experiencing, that'd be awesome!

Thanks,

-Mike
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: