Closed Bug 144207 Opened 23 years ago Closed 23 years ago

After closing a tab, focus should shift to the most recently focused tab

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: mrmazda, Assigned: jag+mozilla)

References

Details

Because bug 105722 was resolved wontfix as a burden to "excessive preferences", and not on the merits of the alternative behaviors requested, and to which bug 127586 was duped, bug 127586 should be reopened, but I don't have the power to do that, so opening this instead. Currently, when a tab is closed, focus shifts to the tab to the left of the position occupied by the closed tab. I've been unable to find a compelling logic for such behavior. Most GUI users are used to the closing of a window shifting focus to the most recently focused window. This is a sensible expectation that should be preserved within the tabbed browsing paradigm. A wish for this behavior can be found in such places as bug 105722 (and a number of bugs duped to it), bug 115234, bug 131037, bug 144154 and multiple newsgroup threads.
I fully agree that this proposed behaviour is far superior to the current nonsensical one. If selecting which behaviour via preference is denied us (bug 131037), then let's at *least* make sure the *only* option makes sense.
Now we're getting somewhere, mrmazda. This is a sensible RFE, to fix broken behavior rather than adding a pref for it. The requested behavior is how the Windows taskbar works -- even with maximized windows, where you can't see the layering -- so it should be how tabs work too. Even if the current behavior *was* slightly more obvious than that proposed in this bug, the benefit from the obviousness would not be great enough to justify the inconsistency between the behavior of tabs and the behavior of windows. Disclaimer #1: As far as I can tell, this bug is *not* a duplicate of bug 105722, though its neighbor bug 144208 *is* a duplicate thereof. Disclaimer #2: I don't use tabbed browsing. I'm going by common sense, not personal preference. Disclaimer #3: Peter Lairo, if you want this RFE to be implemented, I suggest you refrain from commenting any further in this bug report. Currently your involvement seems to be the kiss of death for any RFE, regardless of its merits. Testcase: 1. Set your preferences such that accel+clicking will open a link in a new tab. 2. Go to <http://mozilla.org/>. 3. Use Shift+accel+click to open `At a glance' in the background. 4. Use Shift+accel+click to open `Feedback' in the background. 5. Use accel+T to open a new tab to your home page. 6. Switch back to the `mozilla.org' tab. 7. Use accel+click to open `Roadmap' in the foreground. 8. Close the `Roadmap' tab. Test A: focus should return to the `mozilla.org' tab. 9. Close the `At a glance' tab without focusing it first. Test B: focus should remain with the `mozilla.org' tab. 10. Close the `mozilla.org' tab. Test C: focus should change to the tab containing your home page. --> Tabbed Browser.
Assignee: mpt → jaggernaut
Status: UNCONFIRMED → NEW
Component: User Interface Design → Tabbed Browser
Ever confirmed: true
QA Contact: zach → sairuh
Summary: [RFE] After closing a tab, focus should shift to the most recently focused tab → After closing a tab, focus should shift to the most recently focused tab
Component selected as filed (UI design) was based in part on http://bugzilla.mozilla.org/show_bug.cgi?id=108938#c57. This bug is an apparent dupe of bug 115234. Yet, that bug was duped to bug 105722, which is what mpt@mozilla.org.uk duped the behaviorally inconsistent companion bug 144208 to. It seems apparent from the disposition of these bugs and bug 131037 and the many bugs duped to them that: 1-There is no consensus among the many involved in the discussions in these bugs what the appropriate close behavior should be. 2-Most participants in those discussions think that there is at least one behavior compellingly preferable to the current close tab behavior. 3-There must be some higher power determined that the current behavior be retained. news:netscape.public.mozilla.ui thread "Close Tab Behavior" started <3CE10EB4.ED10E5CA%40atlantic.net>.
Here is my usage pattern: Open a bugzilla query Ctrl click on each bug link in turn, opening 50 tabs. Go to the last tab. Press End, check the last comment, press Ctrl-W, repeat. If I need to comment on a report, I leave it open and go on to the next one. If it went back to the bug list each time, I would go insane. (More insane.) Sometimes my usage pattern is slightly different: Open a bookmark group of 20 rumour and blog sites. Read the first one, ctrl-clicking on each interesting link. Press Ctrl-W. (Focus is on the next tab, which is now the first one.) Repeat. If a page is particularly interesting, I leave it open, so I'm working from the second (or third, or fourth) tab. When I close it, focus returns to the first (or second, or third), meaning I have to move one tab to the right (a predictable focus change). Occasionally I then jump back to these interesting pages to compare notes. If when closing the tab I couldn't predict where focus was going to go (left, right, elsewhere? Which was the last focussed one?) I would be very confused, as I would have to hit Ctrl+PageDown a differing number of times to reach the "next" tab. Now, whether closing a tab moves to the left or the right isn't important -- it just favours one of the two scenarios a little (and when I don't skip any tabs, so I'm working from the edge, they are equivalent). Moving the focus to the last focussed tab, on the other hand, is IMHO confusing. This isn't an issue with windows, because windows don't have a set order -- their order changes as you move around different windows. And the taskbar (on my setup anyway) is alphabetical, not chronological, so it isn't a good comparison. The better comparison is with the Windows alt-tab widget, which is shown in the order of the windows -- close the top one, and the next one opens. Switching to the "last focussed tab" is also quite underspecified, if you consider that (a) maybe none of the other tabs were ever focussed, (b) the last focussed tab might have been closed (hit close twice, background JS could close the tab, etc), (c) what if the last focussed tab is now in another window? (Assuming we ever get the feature to move tabs across windows). Finally, note that this is not the way it works in any other application I use (mainly X-Chat and XEmacs).
I have just tested six applications with tabbed interfaces: EditPad Lite (http://www.editpadlite.com/), Microsoft Excel, Lotus 1-2-3, Opera, ChatZilla (!) and OpenOffice Spreadsheet. None of them behaves the way this RFE suggests. EditPad, Excel, Opera and OpenOffice behaves like Mozilla, Lotus 1-2-3 and ChatZilla does the same except that closing a tab moves to the right rather than to the left. Mpt, you speak about <quote>the inconsistency between the behavior of tabs and the behavior of windows</quote>. IMO the consistency between Mozilla and every other (AFAICT) application which implements tabbed browsing is far more important. Besides, my usage pattern is precisely the same as Hixie's, and implementing this RFE would be a severe loss in usability for me. I suggest WONTFIX. (On a side note, I don't have a strong preference about whether to go left or right when closing a tab, but I am currently slighly in favor of going right.)
Of the six apps you listed, only one is a browser. That presents Mozilla with an(other) opportunity to take a usability lead away from Opera. The parallel to the windoze taskbar is not the only one the requested behavior would parallel. It would also parallel the default back button behavior on every browser I'm aware of: last page accessed.
> Of the six apps you listed, only one is a browser. Let me add Netcaptor. Haven't tested it myself, but I've heard that its behavior is the same as Mozilla's. > That presents Mozilla with > an(other) opportunity to take a usability lead away from Opera. As already explained, this would be a usability *loss* for me. And Hixie. And his cats as well, I'm sure. > It would also parallel the default back button behavior on every browser I'm > aware of: last page accessed. That is incorrect. Clicking Back takes you one step back in session history from where you currently are. If I click the little arrow next to the Back button and go, say, three pages back, clicking the Back button again goes one step further back. It does *not* go three steps forward to the page I was viewing before, though that is the last page accessed.
Anyone who commonly opens 20-50 tabs at once is a ~.01th percentile user. The other ~99.99% who open fewer than 20 tabs should be favored over those few if everyone can't be accomodated with preferences. The last comment #7 statement supports bug 144208, not the status quo. Taking the back/forward buttons as a unified pair, or when the fwd button is greyed, it/they do/does parallel the requested behavior, the idea being step retracing, not something arbitrary like we have now. I have no problem with you two being able to use the current behavior, just not at the expense of the overwhelming majority who would find just about any other behavior better that what's current. But, because there are already "too many prefs", we can't have that, so the only "choice" needs to satisfy the largest possible number, which surely is something greater than .01%.
Please provide backing for your numbers. I have no evidence to suggest that my behaviour is the more common one, nor evidence to suggest the opposite, which is why I have refrained from making such claims. I am interested in knowing your usage pattern. How do you expect to use tabs with the feature as you request it? A detailed summary such as mine (in comment 4) would be nice. Also, how do you propose to solve points a-c in my first comment? Also, please be wary of trying to draw conclusions from analogies. It is too easy to stretch them past their relevance.
I see nothing new in this proposal that hasn't already been hashed out ad nauseum in other bugs and in the newsgroups. Tabs are not MDI windows, they don't have any concept of layering, which is what gets the 'last focused' behavior in other, non-tab windowing systems. Our current behavior is simple, predictable, and consistent with other tabbed browsing products, and we have no plans to change it. cc marlon for UE input.
I think we're looking too hard at this. tabs are not like windows (maximized or otherwise), the user is presented no tangible model for their ordering. there is no way for a user to reaccess the system's order of tabs, proposed by this bug, except by relying on human memory. we just had a CHI conference topic on cognitive psychology, and drawing from that this idea would rely far too much on user's working memory of tab order.
wontfix
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
VERIFIED since module owner has made the call that he doesn't want to change this
Status: RESOLVED → VERIFIED
Blocks: 101794
Since there was such a debate on this issue, I would have suggested in the end the same as comment #73 of bug 105722. On comment #5 here: As said by others, only one app was a browser. Chatzilla as a comparison is not really relevant, because it is part of Mozilla. Also Chatzilla is not relevant, because it conveniently displays the same behaviour, and other IRC applications are not considered in the comparison, like mIRC, which behaves as the summary of this bug requests. Comparing a browser with work related applications like word, excell, openoffice is less relevant. Comparing with mIRC which is also an internet application and in which a user may actively follow many threads and constantly switch between them is more likely adequate then an application like Word. The way tabbed browsing work in Mozilla and Chatzilla, may as well drive mIRC users away from using it in Mozilla and from using Chatzilla at all. Also, Word and Excel, openoffice prefer new windows (handled by OS UI). Other applications that do not use tabs, are work related, but use child windows behave as requeste in the summary of this bug when a child window is closed. (See Photoshop, Illustrator, Acrobat, Corel) Notetab is a text replacement of Notepad which uses a tabbed interface for multiple file editing. It is a work related app, but it behaves as requested by summary. Although comment #73 of bug 105722 is most fair to all, also requires more effort in implementation, I strongly suggest REOPEN for this bug.
Re comment 4-a: I don't see why it should matter. A fallback behavior can be used. I've never caused a tab to open and not get focus for at least an instant. Re comment 4-b: If a tab without focus was closed, then it wasn't the last focused. Re comment 4-c: Invalid, since that isn't currently possible. Re comment 9: The numbers you want, to my knowledge, don't exist. I was trying to make a point that based upon the comments offered in this and related bugs that the current behavior is the least or next least desired of those proposed to be in prefs. Personally I can't imagine that 50 tabs open at once is not also an exaggeration. My usage pattern is only partially a pattern. Normally Google is in tab 1, commonly used local files are opened in #2, my and cc Mozilla bugs are opened in #3. The balance don't follow a regular pattern, which is why I was seeking the help of the UI (bug 131037 & bug 144154) to help me do what I can't do myself via a choice of last focused (this bug) or parent (bug 144208). I can't picture using any of the others much if at all. Re not/not like windows/layers: Maybe the gods didn't design them that way and don't want them to be thought of that way, but they make an excellent functional substitute or replacement for, particuarly of those which stack directly over other copies of the same. The fact is that currently tabs to have two layers, the current, and all other, evidenced by the appearance of the tabs themselves. The lack of a tangible modeling order (comment 11) is justification for implementation of bug 131037 or bug 144154, helping to provide something now missing. The user shouldn't need to remember ordering of individual tabs. He should be able to rely on Mozilla to do the remembering in a fashion he finds most useful. --- I think of the requested behavior as the functional equivalent not only of the last window paradigm, but also of the back button. I think of the ability to retrace steps as fundamentally important. The current behavior prevents it except in limited circumstances. I hope someday soon this module gets a new owner with an open mind.
> Also Chatzilla is not relevant, because it conveniently displays the same > behaviour, and other IRC applications are not considered in the comparison, > like mIRC, which behaves as the summary of this bug requests. mIRC cannot possibly behave as the summary of this bug requests since mIRC does not have tabs. What it does have is MDI child windows along with a taskbar which it calls a "switchbar".
*** Bug 148099 has been marked as a duplicate of this bug. ***
after filing bug 149786, which was declared a duplicate of bug 105722, i am asking you to please REOPEN this one. as many users have explained in bug 105722, the current tab behaviour is "predictable" (peter trudelle), but totally COUNTER-INTUITIVE. tabs are not windows, but they are expected to be arranged not only on an x-axis (first opened to last opened), but also on a z-axis (last viewed to first viewed). that's why you say you "bring them to front" or "open them in the background" (as opposed to "open them to the right"). when you close a tab you expect the one that was front-most before to come back to front. it's that plain and simple. i am NOT asking to copy the behaviour of chimera tabs (see bug 105722 comment seventy-eight) or to implement opera's mdi child windows (see this bug comment #16), but to (1) implement a Z-ORDER for mozilla tabs and to (2) add a "SEND TO BACK" option to the tab context menu (right above "close tab"). (2) is necessary because after opening multiple tabs in the background, closing one of them would always bring their "parent" tab to front (unless it could be sent to back), which is not the desired behaviour. both this bug and bug 105722 are about tabbed browsing in mozilla being counter-intuitive (which it still is), and my impression is that they have been closed for purely ideological reasons.
*** Bug 149786 has been marked as a duplicate of this bug. ***
*** Bug 153264 has been marked as a duplicate of this bug. ***
For what it's worth, I also think this issue should be reopened, and have registered my vote for it. Is there any way to get a usability professional's opinion on this, or perhaps have a general referendum? :) I agree, there seems to be personal opinion blocking this, and I'd like to see what the prevailing opinion among the Mozilla user community is.
An additional note: Has the application/system performance angle been discussed? I find that if the tab to the left of the one I'm closing hasn't been viewed in a while there's often a bit of disk churn and it comes up slowly. Obviously the data has been swapped to VM on the disk. Avoiding this would be a good thing, I would think.
If you could show how this performance problem is related to the current tab closing behavior, then you've got a new argument, otherwise you just need more RAM. BTW, the burden of proof is on those who want to change the current behavior, not on those who support it. If anyone has compelling evidence that such a change is called for, present it. Continued appeals to opinion or voting, without such evidence, are a waste of everyone's time. Please take it to the newsgroups, and stop spamming this verified wontfix bug.
To follow up on comment #5, and in the interest of providing more complete information relevant to this discussion (with apologies to trudelle for spamming his mailbox), editor views in Eclipse IDE work very similarly to Mozilla tabs. Except that Eclipse does have a concept of most-recently-used Z-ordering, both for closing and switching windows. It works great and feels natural. As for the usage pattern described in comment #4, I have also switched to something similar when using Mozilla, but only because it forced me to do it, as any other usage pattern would drive me (more) insane. :-)
*** Bug 164809 has been marked as a duplicate of this bug. ***
See also bug 115215, add an extra shortcut (perhaps Alt+~) for switching tabs in order of most recently selected.
*** Bug 183023 has been marked as a duplicate of this bug. ***
*** Bug 186285 has been marked as a duplicate of this bug. ***
*** Bug 197526 has been marked as a duplicate of this bug. ***
*** Bug 205073 has been marked as a duplicate of this bug. ***
*** Bug 207811 has been marked as a duplicate of this bug. ***
*** Bug 220739 has been marked as a duplicate of this bug. ***
*** Bug 223223 has been marked as a duplicate of this bug. ***
*** Bug 225277 has been marked as a duplicate of this bug. ***
*** Bug 240989 has been marked as a duplicate of this bug. ***
WTF? Why won't this be fixed?! Obviously it is a feature that's just meant to be! Perhaps I'm reading this wrong, but this is hard to believe that "WONTFIX" is the status.. my sympathy to everyone. :(
I've got a lot to say on this (summary: I'm for it) but I don't have time now to write the comment the way I'd like [also, it looks like no-one is listening]. I'd like now, though, to answer a point brought up by Hickson in comment #4, and challenged again by him in comment #9: ''' Switching to the "last focussed tab" is also quite underspecified [ what do you do in 3 odd situations ] ''' Answer: Who cares. It's the more common behavior which matters. I suggest the completely obvious: "the most recently focussed available tab", and put unfocussed tabs somewhere into the mru list when they are created. But if it were to pick a tab at random in these unusual cases, I doubt anyone would be bothered (not any more than they currently are, anyway). If your concern is that a linked-list would complicate the data structures: Just put a sequence number on each tab when it's created, and update it when it's focused. When a tab is closed, search for the largest #. Trying to save, at most, a few thousand CPU cycles by using a linked-list here is silly. The worst-case downside of any 'next-tab' decision is that the user has to go on a tab-hunt when they might otherwise not. Let's try to keep this in mind. My position in brief: In tab usage patterns I commonly use, with as few as 2 or 3 tabs open, the current behaviour is worse than random behaviour, since random behaviour would more frequently save me a tab-click. I have not been able to find a way to change my pattern to improve this.
See also bug 178556, same bug for Firefox.
I also think that this should be re-opened. Many have discussed the fact that tabs are not the same as windows. But how does this matter exactly? How does tabs differ from windows in terms of layering? It's a poor argument against it. Many people, once they open more than a certain number of windows, aren't going to remember exactly where each one is anyway. They are more likely to, however, remember what page they used last. I think it makes more sense in terms of how people end up using a browser. And this is a case of where the user, and even experts are not a good judge of what is better. What needs to be done is some real usability testing. I'm prepared to do this, but it can't be done unless there is some patch or extension do a test with. And on another note. Yes, mIRC does have tabs. Sure they look like buttons, just like the taskbar, but there are basically the same thing in terms of how they are used. People here really need to stop getting caught up in the whole "are tabs supposed to do this?" thing, and think about (well, test for) what is best for the user. Don't forget, tabs were never really designed for this type of thing to begin with, so they shouldn't be compared to the previous concept of tags anyway, since the original use of them was different. Does anyone know how Safari handles this, BTW? There is obviously enough opinion here to re-open this anyway. If the module owner doesn't want to re-open this, then perhaps ownership needs to be transferred to someone who would like to try and resolve the issue? (Sorry if this is wrong, I do not know how this part works.) After all this is a community-based, open-source project, isn't it? I really do think that this is something that needs to be tested, not debated about with theories of what the user /might/ do, as this is quite oftern wrong.
My bug was just dup'ed to 105722, and this seems to be the most prominent successor of 105722. 1.) This bug is marked "resolved-wontfix", as are almost a dozen similar bugs. 2.) Looking at some of these bugs, they still seem to get *several dup's per week*! So obviously many people feel that this is definitely something which needs to be fixed. 3.) From a user's perspective, if I open some sub-page (or popup) of some tab, and close it again, I expect to see the original tab. Period. Anything else is definitely a bug, and disrupting my work. 4.) The second-most-widespread open-source browser, Konqueror, does the (intuitively) right thing most of the time, and people seem to be more happy with it. This clearly and undisputably demonstrates that this is something which can be improved and should be improved. I don't care about the theory behind it (whether parent or Z-ordering), and I don't care what is done in rare corner cases (e.g. when the parent no longer exists or when I work with two groups of pages alternatingly), I just want my browser to do the intuitively right thing in as many of the cases as possible. The current behaviour is intuitively wrong w.r.t. most user's expectations in most cases, and is the worst of all possible choices, so any change (no matter whether based on parents or Z-ordering) is a vast improvement. I observed myself for several hours now. At least for my surfing habits (in Konqueror, not Mozilla, strictly using a single window with tabs only), Mozilla's current method would top the wrong tab after at least 80 % of all tab closes (because it also opens the tabs in the wrong place - opening them right of the parent would already help a lot). Of these > 80 % fails, both proposed methods would fix about 90 %, they would differ only in less than 10 % (because in practice the simple and obvious cases occur by far more often than the complicated and hard-to-decide ones). So, pleeeease, reopen one of these bugs, and do something about it. Don't discuss about 10-20 % complicated corner cases, don't worry what the perfect solution is (there is none as long as mozilla can't read our brains), but fix the 80 % simple and obviously wrong cases first, otherwise mozilla is falling behind the competition. There won't be an immediate perfect cure, but we urgently need a first relief from the major pains this misbehaviour causes in daily work. By the way: During my several-hour usability self-study, I noticed that at least w.r.t. my expectations, the parent algorithm would have done the right thing slightly more often than Z ordering: * I work with a group of related tab's, let's call them "A". * My work get's interrupted, e.g. by some newly arrived mail with links in it or whatever. This leads to another group of pages, let's call them "B". * After looking at some "B" tabs, I decide to investigate "B" more closely later. Hence, I leave the "B" tabs open, but continue my work in the "A" group of tabs. * Now I close an "A" tab which I looked at before "B" was started. The parent algorithm takes me to the "A" tab from which the closed tab was opened. This meets my expectation, because I'm concentrating on "A" matters now. The Z-ordering algorithm would have taken me to the last "B" tab I've looked at, which isn't quite what I'm looking for at that moment.
There are extensions for Firefox that do this now. It was the first thing I installed after Adblock. So guess which side of the debate I'm on. :-) But hey, what's to be done. The options have been discussed extensively, module owner made the call, and chances of this bug being fixed are slim to none. Thank god at least the extensions now let one get one's own preferred behaviour. Did anyone notice that there is no Bugzilla discussion more heated than in UI bugs/RFE's?
Well, then could anybody please point me to an extension which provides this and works well with Mozilla 1.7.3? No Firefox here any time soon... However, extensions are no excuse for bad base functionality: They tend to interfere with each other, they may lag behind browser versions, they require extra installation and upgrade efforts, ... Extensions are the worst way to go w.r.t. software managability. Mozilla should be aiming towards enterprise class software, not a hackers and freaks paradise. (Are you using tons of macro's authored by individuals from all over the world for the microsoft office programs in your enterprise? Does your IT department support all these macros? Come on...) If something is widely seen as a problem (like this), it should be fixed in the base. And about discussion: That's ok. Anything which costs time/nerves/mouseclicks/... in everyday use is worth discussions. And (excuse my unfriendlyness) the argument for staying with the current algorithm was extremely provoking: A technical argument like "it just goes to the preceeding tab - easy to understand and absolutely predictable" is no excuse for a misbehaviour which ignores the user's needs, doesn't meet his expectations, and hinders his work. Ok, I can predict that things will go wrong after I close a tab, and I fully understand why they go wrong. Does that help me in any way? Does it save my any mouse clicks? Can I use this knowledge to improve the situation or avoid the misbehaviour? No! Let's make an analogy: Assume that your car dealer's representative explains to you that the steering of your new car works the same way as the steering of electric bumper cars in fairground attractions: It will wrap around from extreme left to extreme right and vice versa. Understandable? Yes, of course. Technically sound and simple? Yeah. Predictable? Absolutely. Useful under very limited and special conditions? Likely. In spite of that, will you like it in everyday driving and parking? No!!! If other cars are offered which work the way you expect: What will you do? See... (sorry, couldn't resist, I've been the head of a software company's QA department for some years...)
*** Bug 277643 has been marked as a duplicate of this bug. ***
*** Bug 279574 has been marked as a duplicate of this bug. ***
How can someone be so ignorant and close this as WONTFIX? This behaviour is totally nonsensical! I you have a piece of paper and put another on top of it then take it back again you surely see the last piece of paper again, not some other right? Frankly I don't care how many other pieces of software make the same mistake (probably only for the sake of a cheap implementation). The current behavior is totally random at first, certainly not predictable because totally unexpected. I demand to reopen and finally fix this. If not, at least point me to an extension please!!! Sorry for ranting but I simply cannot believe that there is even so much discussion about this. This sure *is* a but (as backed by the many bug reports).
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.