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)
Thunderbird
Toolbars and Tabs
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)
10.69 KB,
patch
|
Details | Diff | Splinter Review |
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 ...
Comment 1•15 years ago
|
||
Confirming as an enhancement to the current implementation.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-thunderbird3+
Updated•15 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Updated•14 years ago
|
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)
Updated•14 years ago
|
Whiteboard: [gs]
Comment 4•14 years ago
|
||
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.
Updated•14 years ago
|
Whiteboard: [gs] → [gs][UXprio]
Comment 5•14 years ago
|
||
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..
Comment 8•14 years ago
|
||
(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 :) .
Comment 9•14 years ago
|
||
It is a great feature in Firefox 3.6.8. Why is it not renewed under thuinderbird 3.x?? I vote for its use.
Comment 11•13 years ago
|
||
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]
Comment 12•13 years ago
|
||
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!
Comment 13•13 years ago
|
||
With two updates in the last week, you'd think someone would have addressed this annoyance by now?
Comment 14•13 years ago
|
||
(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
Comment 16•13 years ago
|
||
(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.
Comment 17•13 years ago
|
||
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.
Comment 18•13 years ago
|
||
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
Updated•13 years ago
|
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)
Comment 19•13 years ago
|
||
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)
Comment 20•13 years ago
|
||
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)
Comment 21•13 years ago
|
||
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."
Comment 25•13 years ago
|
||
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.
Comment 26•13 years ago
|
||
(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.
Comment 27•13 years ago
|
||
really, i think the gist of this issue is well understood, and all we need is a patch. thanks.
Severity: enhancement → minor
Comment 28•13 years ago
|
||
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.
Comment 29•13 years ago
|
||
The fact that the issue persists doesn't mean that it isn't well understood. Please, no more comments unless you have a patch.
Comment 30•13 years ago
|
||
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)
Comment 31•13 years ago
|
||
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)
Comment 32•13 years ago
|
||
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.
Comment 33•13 years ago
|
||
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.
Comment 34•13 years ago
|
||
(This can be done in concert with the tabs-on-top work, right Mike?)
Assignee: nobody → mconley
Assignee | ||
Comment 35•13 years ago
|
||
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?
Assignee | ||
Updated•13 years ago
|
Depends on: tb-tabsontop
Assignee | ||
Comment 36•13 years ago
|
||
Here's my first run at a patch. I'll write some Mozmill tests next.
Assignee | ||
Comment 37•13 years ago
|
||
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
Comment 38•13 years ago
|
||
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
Comment 39•13 years ago
|
||
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?
Comment 40•13 years ago
|
||
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.
Comment 41•13 years ago
|
||
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.
Comment 42•13 years ago
|
||
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!
Comment 43•12 years ago
|
||
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
Assignee | ||
Updated•12 years ago
|
Whiteboard: [gs][UXprio][firefox-parity] → [gs][UXprio][firefox-parity][mentor=mconley][lang=js|xbl]
Assignee | ||
Comment 44•12 years ago
|
||
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
Comment 45•12 years ago
|
||
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
Comment 46•12 years ago
|
||
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!
Comment 47•12 years ago
|
||
Is the try-comm-central-macosx64/ what I need for Win7 64bit?
Comment 48•12 years ago
|
||
Never mind that last - I realized just as I hit "Save Changes" that macos means Mac OS... <dunce cap>
Assignee | ||
Comment 49•12 years ago
|
||
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 50•12 years ago
|
||
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+
Assignee | ||
Updated•12 years ago
|
Attachment #618352 -
Flags: review?(squibblyflabbetydoo)
Assignee | ||
Comment 51•12 years ago
|
||
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)
Comment 52•12 years ago
|
||
Works great! Thanks for making these improvements. Hope to see this implemented in an upcoming release for TB
Comment 53•12 years ago
|
||
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+
Comment 54•12 years ago
|
||
Would someone please advise as to which package I should download for Win7?
Assignee | ||
Comment 55•12 years ago
|
||
(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
Assignee | ||
Comment 56•12 years ago
|
||
Fixed the formatting in the tabmail documentation as requested in squib's review.
Attachment #618406 -
Attachment is obsolete: true
Assignee | ||
Comment 57•12 years ago
|
||
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
Comment 58•12 years ago
|
||
Is there any particular reason why Firefox doesn't do this as well (defaults to adjacent tab on close)?
Comment 59•12 years ago
|
||
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.
Assignee | ||
Comment 60•12 years ago
|
||
(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.
Description
•