Closed Bug 105722 Opened 23 years ago Closed 19 years ago

Closing tabs should return to 'parent' 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: eem12, Assigned: jag+mozilla)

References

(
URL
)

Details

If I choose 'Open in New Tab' from the RMB context menu and close the new tab,
focus is always returned to the last tab, regardless of which tab I was looking
at previously.
The way other implementations handle this that I've seen is that they open the
new tab immediately to the right of the originating tab, so that closing it will
naturally cause the parent to be selected.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
*** Bug 105819 has been marked as a duplicate of this bug. ***
That sounds like a reasonable idea.

Just opening a new tab to the right wont help: E.g.:
1. have 2 tab
2. open one new tab having the left one active -> new one is the middle one
3.  activate the left one
4. open a new tab -> this will be the second from left to right
5. activate the left one
6. activate the 3rd one from left to right -> close it
7. now the remaining middle one will be selected, not the last selected.

Making a new tab for me mostly occures by selecting a link and saying open this
as a new tab (I'd also like to have this as default for middle mouse button :)
but sometimes (often) I open more than one tab while the other new tabs are
loading. After this loading-phase I check, if the contents is what I need. Now I
close the unneded and like to get back to the tab, where it originated OR where
I were just before.

So there a two approaches to me:

1) make a double linked list where the tabs are chronological listed by it's
activation state. So closing the active tab would be like an undo to the "new
tab" command.

2) Make a tree where is remebered, which tab was the origin for a
"new-tab-from-link" tab. So closing such a tab jumps to the origin-tab. In this
scenario it's not clear, wha to do, if you close a parent -> kill all childs,
too? Or make it the childs to the parent of the closed tab?

I'd prefere the linked list -> the activation-undo behaviour.

*** Bug 106638 has been marked as a duplicate of this bug. ***
*** Bug 106975 has been marked as a duplicate of this bug. ***
Target Milestone: --- → mozilla1.0.1
I doubt that many users have any model for parentage in this scenario; while the
current behavior is simple enough that it is extremely predictable, and unlikely
to be a source of defects.  
Actually, users will probably expect tabbed windows to act like taskbar windows in Windows 9x - closing one will show the last one you had open. So all you need is an internal list of when each tab was last viewed, and work back through the list in chronological order as windows are closed.
The solution, that was suggested in comment #8 is obviously what users expect.
This is how it works in Galeon and in Opera. For me this is the most annoying
annoying thingy in Mozilla but luckily those annoyances are rare ;) 

I think this should be fixed earlier than mozilla1.0.1 (IMHO ASAP).
I completely agree with comment 8. Doing so will also solve the bug as it is
described: opening a new tab will automatically place the new opened tab just
before the parent tab in the list of last opened tabs.


I agree that comment 8 is the direction we should go, but I would point out that
this is different than the original bug description.  Consider opening a new tab
C from tab A, switching to an unrelated tab B, switching back to tab C, closing
tab C.  The original bug says we should return the focus to tab A, while I and
other recent people are saying that the desired behavior is to return to tab B.
*** Bug 111769 has been marked as a duplicate of this bug. ***
spam: set your filter for "SeverusSnape" to avoid the influx of bugmail

changing QA contact of open tabbed browser bugs from blake to me. if this bug
requires a reassignment, however, feel free to change it!
QA Contact: blakeross → sairuh
In the absence of a consensus as to whether "parentage" should be followed when
closing tabs I would suggest that moving to the tab to the right is more
suitable than moving to the left.

This is I frequently open many tabs from a page that has a lot of links.  I will
then switch to the first tab I opened, giving the content in the other tabs time
to load, then when I close this I expect to move to the next tab (to the right).

A more specialised version of this behaviour is "switch to the next tab that was
opened (i.e., time based test) or the previous if no tabs were opened after this
one" but in general the "move-right" rule applies.
I don't think "move-right" and "move-left" rules are very good ones, since
chronological ordering has little to do with positional ordering (in the
general case), and the principle of least surprises seems to suggest that
"recency" is a better gauge and so I would lean towards suggesting that. 
When arbitrary combinations of tabs are opened and closed, what's to the
left and right of a tab may have nothing to do with what the user expects
to "go back to" when closing a tab.

As someone else noted, keeping a "recency" ordering for tabs is what other
tabbed browsers seem to do, and is what Windows does with its start-bar.
Thus, by the "principle of least surprises," closing a tab should go to the
next-most-recent tab.  In other words, I vote for the behavior in #8.

Spawned bug 115234 for comment #8. Recommend users to change their vote if
necessary.
Unfortunately, comment #8 ignores the case of background-opened tabs,
so we need a slightly more complex rule to actually solve the problem.

Here's what I'd like to see.  When opening a new tab in the background,
the tab is placed into the MRU list at the top, just above (closer to
the head) the current tab (leaving the parent tab in its current spot
in the list).  Then, when the user starts to read the background-opened
tabs, they are all visited (often in the order they were created) before
returning to the parent page.

The linked-list manipulation rules are simple:  when switching to a new
tab, we move it to the top of the list (if it isn't there already), and
when we close a tab, we remove it from wherever it is in the list and
switch to the head of the list.

Visually, I like the idea of placing the new tabs in the tab bar
directly to the right of the parent tab, but that's not a requirement
for this to work.

Here's an example user interaction:

I'm browsing with tabs A & B open (visible in that order in the tab
bar).  From page A I open some tabs in the background:  A1, A2, and
A3.  If we put the tabs to the right of the parent, the tab bar looks
like this:

A A3 A2 A1 B

If we don't, it looks like this:

A B A1 A2 A3

In either case, the linked list looks like this (from head to tail):

A1 A2 A3 A B

This is true even though we're currently viewing tab "A".

If I were to close tab A, I would view A1-A3 (closing each one as we
go).  If I were to instead click tab A2 (instead of closing A), I
would visit A2, A1, and A3 in that order (closing each tab in turn)
before returning to A.

What we don't want to implement is adding new background tabs below
the parent in the list (as if you had opened the tab in the foreground
and then switched back to the parent tab instantly).  The reason for
this is that every link in the set of new backgrounded links would
return to the parent page when closed (which would be very annoying),
and the links would be browsed in the reverse order of their creation
(which is not the best idiom for background tabs, I think).
The second paragraph of comment #17 should not contain the phrase "at the top".
 The sentence should read:

When opening a new tab in the background, the tab is placed into the MRU list
just above (closer to the head) the current tab

Sorry about the confusion...


should this or bug 115234 be the way to close tabs? nominating nsbeta1, over to
ui to give input --then reassign as needed. thx!
Assignee: hyatt → marlon
Status: ASSIGNED → NEW
I think the currently implemented behavior (close causes switch to tab on left,
if it exists, else tab on right) is about as simple and predictable as we could
get.  I don't think I could ever predict the behavior of any scheme that
considered 'parenting' (which I think is a foriegn concept here) or
'last-opened'.  Besides, the current implementation also matches the latest
Opera and NetCaptor releases, despite comments above (ability to rearrange shows
it is not 'last-opened').  I think this bug should be resolved as 'invalid' or
'worksforme'.
I strongly disagree with PTrudelle's "reasoning". I, as a frequent tab user,
often have more than one search engine open, and from there open all kinds of
search results. when i close a search result, i definetely do NOT want to go
back to some other search result (especially not one presented by another search
engine, and maybe even on another search query). I usually want to go back to
the search engine (i.e., the *parent* tab!).

The same argument goes for when i surf starting from more than one "parent" page
(e.g., download multiple custom maps for Wolfenstein :) starting from from
multiple RTCW maps pages (e.g., http://www.planetwolfenstein.com/ and
http://wolfensteindaily.gdcn.de/).

The same goes for any number of usages involving spawning child pages from
*multiple* parents (porn video downloads also come to mind - don't know why)!

After all, spawning (multiple) child tabs and going back to the (multiple)
parent tab(s) is one of tab's greatest assets.

Concerning "predictability": Novice hyperclickers (you know the type - those who
click before they think) who open multiple tabs from multiple tabs will probably
be more confused if when they close some tab, they are returned to the tab on
the left which is completely unrelated to the tab they just closed AND unrelated
to the parent of the tab they just closed. Most users will likely want to stay
withing the "subject" they are currently working on (not some unrelated tab that
happens to be on the left of the tab they just closed).

Also, the fact that PTrudelle suggested to resolve this bug as "worksforme"
makes me wonder if he understands what is being talked about here. How is what
is being asked here currently working?
Peter Lairo, why do you feel the need to continually question my competence? 
You must think I'm a drooling idiot, since every time I disagree with you, you
claim that I don't understand the problem.  Why can't you just stick to the
merits?  Such ad homeinem behavior is the mark of a weak argument.

The current implementation allows for repeated invocations of the close command
to iterate through a list of tabs from right to left, rapidly closing them in a
known order.  This is exactly the same behavior as other popular apps that have
tabs.  Adding some purported "parent" behavior is wrong, because there is no
such relationship between the tabs, except in your mind.  This becomes clear
when you consider re-ordering of tabs, dragging new links into them, or just
loading new URLs.  Once you have done any of these, it would become very
unpredictable which tabs would be  focused next in most of the complex schemes
that have been proposed. 
As a human I'd like to make the machine (computer) make what I want and not make
me what the computer wants. So the argument: the simple scheme: closing a tab
activates the left tab may be simple, but is it what I want.

So I think a program like mozilla should mimic as best as it can, what I want it
to do. This _communication problem_ should be solved by a simple intuitive
language (eg. clicking with a mouse).

When I open a new tab I want the original www-page kept open (e.g. google). But
why? I see the origin page as a bag in which the other tabs lie. So that's my
hierarchical view. This _internal_view_ can be represented by tabs in a window.
Whenever I want to open a new context (no page in an allready opened bag) I
could start a new window.

So perhaps we could keep this scheeme and make "middle button" open a new window
(new context) and make "shift middle button" open a new tab (keep the context).

But keep in mind: only a program _understanding_ the will of a user will be used
by the user. Make it easy (efficient) to tell the program what the user wants.
The merits: The "known order" of right-to-left is an order relevant only to the
abstract concept of "tabs". The relevant "known order" is that which the user
has in his head, namely the order in which he *thinks* about the opened
windows/tabs. It is now up to the great minds at mozilla.org to try to determine
what mental order (hierarchy) the user has in his head, and then make Mozilla
conform to this order - not the other way around. Maybe this is something that
should be discussed in the newsgroups.

My suggestion is that the user thinks in terms of "hierarchichal tab-groups"
(i.e., parent-child relationships) - not right-to-left tab orders.

Right-to-left pertains to the tabs themselves. Parent-child relationships
pertain to the contents. It's the content, not the tabs, that are what counts to
the user.

Only if there is no parent-child relationship should we fall back to the
right-to-left rule.
*** Bug 115234 has been marked as a duplicate of this bug. ***
please argue in the newsgroup, ere's a nice thread which contains a slightly 
audited version of what transpired in these two bugs: 
news://news.mozilla.org/3C39A266.C84C0B52@mozilla.org
If anyone objects to the redactions they can indicate their objections in the 
newsgroup, however i'd advise that people stick to providing usability 
information and surveys of products that have marketshare.
URL: news://news.mozilla.org/3C39A266.C84C...
OS: Linux → All
I voted for this bug. Return to parent on close of child is the *only* scheme
that makes any sense to me.
Along to Mozilla I still use Opera, and as many others I miss this behaviour of
the tabs very much! Naturally I stand by comment #8!
Huh?  Opera does not work that way, it works as I described in comment #20, just
like mozilla.
I use Opera 5, and I would like the same behaviour. Which is the exact same
behaviour as that of the taskbar windows in Windows 9x. This behaviour is the
common experience of the majority; most new users coming from IE would be turned
off/puzzled by the current behaviour of the tabs.
To make everyone happy, I guess it should be modified to what the majority
wants, and modifiable in the prefs.
Opera 6 works exactly the same as mozilla and Netcaptor.  In other words, all
popular tabbed browsers now work this way.
You should copy "right" behaviours, not broken ones.
I just tested Opera 6 TP2 on Linux with a clean profile (i.e. default settings),
and it indeed returns to the last active tab when closing tabs. It does not
behave like Mozilla does now. Maybe there's some misunderstanding here..?
I'm using Opera 6.0, build 999 on Win2K.  Under what scenario are you seeing
anything other than the behavior I described in comment #20?
Let me give an example from Opera 6.0.  
Open Opera  to default tab #1 (My Opera) 
New Page -> tab #2
Load http://mozilla.org into tab #2
Go back to tab #1
right click on any link, select Open in New Page.
<link opens in new tab #3>
Close Page
<Focus goes to tab #2, not last active, "parent" tab #1>

Under what circumstances does anyone see focus in any tab browser go back to a
last active, "parent" tab that does not follow my description in comment #20?


Ok, I also tried Opera 6.0, build 1010 on W2K. I followed the steps above, and
it returned to tab #1 when closing the third tab. (That's because tab #1 was
last active, not because it's also the parent tab.) 

I tried various other test scenarios too, and it always returns to last active
tab when closing tabs. I also checked the preferences but didn't find anything
that seems to be related. Pretty strange, eh.
Yup, seems like they can't keep it straight from build to build.
The simplest thing to do to make this better would be to change the position of
newly-created tabs to be immediately to the right of the active tab (as
suggested in comment #1).  This would allow the current "move left on close"
behavior to work a lot like going to the previously-active/parent tab in many
circumstances.  It even works well with background tabs, since you can
background a series of links from one page, and then browse them all in order by
simply clicking the right-most of the new tabs (and closing them as you go).

If a more complex movement on close is implemented, I prefer a previously-active
movement to a parent-tab movement -- the latter would be particularly bad with
background tabs when the user creates more than one at a time from the same page
and then attempts to read all the new pages (since the browser would keep
jumping to the parent tab after every page close).
Could this be fixed ASAP. I just counted the opinions of people on this 
page and only one person seems to think that the tab order handling should 
be left as it is now.

Here are the results:

"comment #8 (Win 9x taskbar like behaviour)" - 6 people supported this with 
clear words
"parentage, the original proposal of this bug" - 3 people, including the 
original submitter
"open links in the right side of the current window" - 2 people
"move to the next one in the right when closing a window" - 1 person
"Two tree like or chronological suggestions" - 1 person 
"Enhancement to comment #8, handling of tabs opened in the background" - 1 
person
"Leave it as it is" - 1 person

Additionally two individuals pointed that tabs in opera behave like win 9x 
taskbar. And I can confirm it, if it really matters to anyone. (I tested it 
with Opera 6.0 build 1010 on Windows NT4, Opera 6.0 TP3 on Linux and Opera 
5.0 on Linux.)

In short, most people want (and expect) Windows 9x taskbar like behaviour. 
I don't think that I need to do a usability study to prove this cocept to 
work. Microsoft has already paid for that study, when designing Windows 95 
and if some other more sophisticated (or less sophisticated, as it is now) 
solution is implemented it should be tested for usability.

- Current behavior is not a defect, since there is no spec (->enhancement). 
- Please clarify why you think close behavior for layered windows should apply
to non-layered tabs, and explain how 'parentage' should apply when creating tabs
by dragging links, especially from a mail/news window.
- 'Most people' are not represented in this bug report, and those satisfied with
current behavior are extremely unlikely to be commenting here. 
- On my machine, running Win2K, the latest recommended download of Opera for
Win32, default config, behaves as I describe in comment #20.  I don't know what
the builds reported by others are. It would be good to understand this better.
- This is not a democracy; having the most opinions in a bug doesn't make it right.
- Please post the results of the MSIE usability study you reference.  ;-)

BTW, I think the proposal and scenario in comment #38 are interesting.
Severity: normal → enhancement
- OK, it's not a defect according to the (missing) spec, but I think it's a 
usability issue.
- Close behaviour should be the same as with layered windows, because 
people surf the same way, with or without the tab/taskbar like interface: 
They open some links in the original window/tab and other links in a new 
window/tab. When they close the new web page, they expect to go back to the 
last open page or parent page. Most people will not want to see the next 
one on the left side, because the page is possibly (or even probably) part 
of totally different context. It might have been opened some day last week 
or it may be a porn site popup... Context: people relate the pages in their 
minds according to context, not the physical location. Also I do not see 
the "tabbed browsing" user interface as an analogue to a tab interface in 
dialog boxes and traditional tab interfaces (MS Office preferences, Excel 
sheets etc.) - in these interfaces you often don't even have an option to 
close the tabs. Web surfing with "tabs" resembles at least as much handling 
windows with a taskbar as it resembles traditional tab interface. (Please 
do not start nitpicking because I assume that people surf the same way with 
layered windows and tab interface. It is an assumption, but I dare to say a 
good one: People are reluctant to change their habits. They tend to behave 
like they have learned before and they will try to use the new interface 
like the old one.)
- I would not like to comment the implementation details of the parentage, 
because I don't think it's the best idea. I think the best way to go, when 
closing a page, is the go to the previous open page. It's easy to unerstand 
and predictable. It's widely used: Windows 9x, NT, 2000, Almost all window 
managers that have a taskbar and most other tabbed browsers behave this way 
(Also most Opera versions ;). Best of all it's very easy to implement with 
a linked list and no exceptions (or very few) need to be handled 
separately: The windows that are opened in the background are just added to 
the beginning of the list, because they will be most probably be selected 
trough the tab interface after they have been loaded and if they are never 
selected, they need to be shown only after all other windows are closed.
- You're right about "most people", the ones that are happy, are not 
complaining and "most people" did not write any comments. But on the other 
hand the same "most people" will just use the software as it is and won't 
complain even if they do find some behaviour awkward. So, I think we're 
even. And why don't you have at least one other person supporting your 
opinion? If open source development is not democracy as you said, it's 
definately not dictatorship either.
- About Opera - I'm happily using it and for all my web browsing. Mozilla 
is running only as a mail client currently, because tabbed browsing and 
speed of browsing are worse in Mozilla. 
- And about the MS Windows 95 (not MSIE) usability study... I'm afraid I'm 
not able to supply the results ;) But I remember reading stories, about 
seven years ago, that the Windows 95 user interface was one of the most 
studied and usability tested pieces of software on earth. The taskbar of 
Windows 95 was kept the same until Windows XP. I think we can agree that 
the taskbar's usability is good enough.

I have spent too much time with this issue already... I regret saying 
anything in the first place ;)

I think I may have solved the Opera 6 mystery.  On my machine, Opera 6 MDI
windows behave exactly as others have described here, returning to the
previously *active* window on close.  Is that the behavior people want our tabs
to emulate?  It is completely appropriate window behavior, but it isn't tabbed
browsing.  If you're seeing rectangular buttons on the bottom of the window
(like Windows taskbar), rather than rounded tabs on top, then you're in MDI
mode, not tabbed.  For Tabs, you need to uncheck Opera's "Open windows inside
Opera workspace" pref.

(BTW, I'm certainly not dictating anything, and if we changed this behavior I
expect there would just be a different group of people complaining in a
different bug.)
my 2 cents:  When this bug was opened and when I originally commented on
it(comment 11), the behavior was that upon closing a tab you would always be
taken to the right-most tab.  This behavior was awkward and confusing causing me
to find this bug and agree that the behavior should be changed to in my eyes the
most reasonable alternative I could see.  Since then the behavior has changed to
always opening the tab to the left of the closed tab.  This behavior has grown
on me, and I no longer think that changing it again would be a noticeable
improvement, and would only serve to confuse current users.  The argument that
keeps going through my mind is: "I just left the last active tab for a reason,
obviously if I left it I must be done with it for the time being, why would I
want to go right back to it?"
*** Bug 121551 has been marked as a duplicate of this bug. ***
*** Bug 123563 has been marked as a duplicate of this bug. ***
BTW: Bug 123563 argues for FIFO ordering.
*** Bug 127048 has been marked as a duplicate of this bug. ***
According to Bug 123563 and Bug 127048 we should keep in mind that the "Load
links in the background" feature might need another behaviour. 

I use this feature for speeding up browsing. And in that case I open several new
tabs and want to read them in chornological order. Thus I think the behaviour
should be:
*In case you open your links in the background* select the right (not left!) tab
when closing a tab. Returning to the parent tab would be rather annoying.


*** Bug 127586 has been marked as a duplicate of this bug. ***
Since this seems to be the melting pot for discussing tab closing behaviour...

I agree with returning to the most recently activated window (as per comment 8),
largely because I want tabs to act like windows wherever possible, and I'm
accustomed to how windows are handled in the Windows taskbar/KDE kicker/GNOME
panel/other.

I would also favor new tabs being opened immediately after the tab they're
opened from.  Many comments here have revolve around what Opera does, and I
think Opera's GUI is excellent as well, but have a look a Galeon, as well, to
see how it does tabs (in particular, it has a pref to insert new tabs
immediately after the current tab).

I don't have easy access to news for the discussion.

"I agree with returning to the most recently activated window..."

Naturally, I meant: ...to the most recently activated/viewed tab...


It just occurred to me that while some very advanced users may be able to recall
the last tab that was active, few (if any) typical users have any model of a
chain of such activations going back further than that. (The only reason it
makes sense with windows is the visible layering) I am certain that following
such a chain would give the appearance of totally random behavior. Even if you
did follow such steps to get to the current tab, why is that necessarily the
most appropriate way back?  Much better to have the extremely simple, visible,
predictable behaviour we do now.
Trudelle@netscape says:
>It just occurred to me that while some very advanced users may be able to recall
>the last tab that was active, few (if any) typical users have any model of a
>chain of such activations going back further than that.

Your contempt for users and their ability to remember what they were
seeing 30 seconds ago is frightening.

The "recency of visitation" ordering is quite natural -- closing tabs and
reverting to things you've seen more recently is much more natural than just
going to the rightmost tab.  These aren't fields in a form, or configuration
panels in a dialog box.  These are browser windows collapsed into a single
window pane to help reduce screen real-estate and perhaps memory usage. 
The expectation that these tabs behave somewhat like the windows they replace
is not unreasonable.

Also, I think it's safe to say that the users with a bajillion tabs open 
are probably at least a little sophisticated, and can handle a similarly 
sophisticated tab-closing protocol.  Perhaps the behavior can be made 
configurable.

I personally tend to browse with many tabs open, several of them are 
persistent "works in progress" tabs.  I also tend to follow links by
"Open[ing] in a new tab," often from my leftmost tab, which contains
my homepage, or the tab next to it, which contains Slashdot.  Going 
to the "tab immediately to the left" when closing the current tab is 
usually very disorienting as a result.

Opening the new tab immediately to the right of the current tab is an
insufficient band-aid.  For long-lived tabs, it's useful to have them
retain their position in the hierarchy of tabs.  Such a hack would break
that while trying to approximate the "recency" ideal.

So, I'm squarely with the behavior asked for in the first suggestion in
Comment #4, which (to my eye) seems the same as the suggestion in Comment #8.

Is there some way to hold a vote on this?  Apparently comment #39 wasn't enough?
I agree on comment #53. But this does not tackle the problem of opening several
links from a newsticker (freshmeat/slashdot/...) in the background, as returning
to the most recent page would mean returning to freshmeat/slashdot/... . This
would be even more annoying than the current situation.

Maybe the user should choose the way tabs are closed (move to left, right, most
recent).
Joseph, I think you've crossed the line in claiming that I have contempt for
users; that is a very antagonistic and hurtful remark.   I had hoped that we
were all trying to make the best browser possible for the widest possible
userbase, but your tone makes me think you just want to get your way by any
means available.  You should know that using such tactics, and even the tyranny
of the bug-majority, are not how we decide things around here.  
You know, it isn't just the last tab activation from perhaps '30 seconds ago',
the chain could go back hours, and may have nothing to do with any of the pages
currently loaded in them.  Who really remembers that, or cares?  Few, if any. 
Tabs are not windows, despite your seeming to want them to be, and they are not
going to blindly mimic them.  Also, we are not designing this feature to require
the sophistication of someone who has a 'bajillion' tabs open, the aim is that
it be usable by intermediate users.  I think you vastly over-estimate the degree
to which such users are willing & able to tolerate complexity in a UI.  This
doesn't make them any less intelligent than you, they just have other interests
they'd rather spend their time and attention on.
personally i don't care what lines people cross but i request that everyone 
cross them in newsgroups instead. trudelle has more important bugs to comment 
in and I have more important bugmails to read.  you guys really are wasting his 
time, and mine.

trudelle: i suggest that this bug be moved to 1.2.0 or beyond and that you and 
everyone else stop wasting bugmail on it.
Blocks: 128632
i agree with comment 8:  the previously focused tab should appear when one is
closed.  this is standard behavior not only for Windows-like taskbars, but also
in most any window manager when a window on a desktop is closed -- and what are
tabs but overlaid windows, framed within another?
->component
Assignee: marlon → jaggernaut
*** Bug 129581 has been marked as a duplicate of this bug. ***
Looks like most of the shouting has died down, but I'd like to point out that
including the bugs duped to this one two completely different behaviors (at
least) are being proposed, which shows the problem/solution isn't as obvious as
some of the most hot-headed partisans seem to think.

Count me in as one of the folks who wishes we went to the right tab instead of
the left, and would absolutely *HATE* going back to the most recently visited
tab. I'd imagine whether you open tabs in the background or foreground has a big
influence on this preference.
I came to bugzilla to suggest this enhancement too. Apparently, I'm not the only
one who fails to see the logic in the current model.

And no, expecting to see the last active tab after closing one is not because I
am using it as a replacement to new windows on taskbar, or whatever.

Consider this..

I open a link in a tab, because of the relative information it will have. I want
to keep this tab open to be able to look back at. I go back to the parent, find
another link, open it in a tab, leave it open, back to the parent, open a tab...
and close this tab. Now of course I want to see the last active tab here (the
first page), not the one left farthest to the right!

And to the argument that "tabbing" is done by opening a bunch of links, then
looking through them, moving from right to left, as the current scheme
defaults... how does this make sense? to open several links at once would
require clicking on a link, back to parent, clicking on a link, back to parent,
etc. 

Or... you would open them in the background.

Which shows that foreground-opened tabs, users logically expect to be defaulted
back to the last active tab. NOT THE RIGHT-MOST ONE

And people who open tabs in the background, would expect mozilla to act the way
it does now.


The idea of opening tabs to adjacent to the parent would make it even more a
mess than it currently is.

Personally, I think the solution is to change it for tabs opened in the
foreground and have tabs opened in the background cycled through the way they
are now, until the parent is reached. But as I have read, it seems not to be
open for discussion. how unfortunate.
sorry, by right-most tab i really meant "left of the one that was closed." argh.

and Opera acts cronologically for me too (build 1041)
At the risk of being called a hothead, or told to shut up (again) ;-)

Sebastian: I just upgraded to Opera 6.0.1 (build 1041), and its tabs still
behave like Mozilla's on my Win2K box.  Are you sure you're not using MDI in
Opera?  That still works as you describe. I'm not opposed to reversing the
left/right sense of the current behavior, if user data shows that is preferable.
 However, I don't think that having different behavior depending on how the tabs
are created would make sense, since there is no necessary relationship between
creating a tab and closing it - there can be many pages opened in it due to
clicking on links or drag/drop in between.  If we added support for reordering
tabs, keeping track of how each one was created would be like a shell game.

nsbeta1- per Nav triage team. ->1.2 until we get a spec.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0.1 → mozilla1.2
> there is no necessary relationship between creating a tab and closing it

True, but the *way* a tab is created (click or SHIFT+click) may give an
indication on how it would best be closed.

This "fine-tuning" is a pain in the a~~, but it is what makes the difference
between a functioning app and a "smoothly" functioning app.
There are several ways a tab can be created, such as when the window is created,
Ctrl-T, Ctrl-click, drag link to tab bar, context menu, etc, and some
unimplemented, like click on new tab button, or open bookmark group.  Once they
are created though, they are all the same, appearing and behaving alike.  I
understand why some very advanced users might want to have different behaviors
on close, but I don't see how most users would distinguish each one to predict
its behavior; it would just appear to be random.  It seems to me like some
people really want to have MDI windows rather than tabs, and the layering it
uses would allow for some of these requested behaviors.
I don't know about that -- think about Windows users and their taskbar. There
are lots of ways new windows can be opened, and the order they appear in the
taskbar does not correspond to their stacking order, but users are pretty
comfortable with the idea that when they close a window, the one they'll see
next is the last one they had been to.
Sure, because they can see it in the window z-ordering, and thereby reliably
predict the behavior.  This is a powerful and fundamental cue, the same physical
principal in use when they remove the top document on their desk, revealing the
one beneath.
> because they can see it in the window z-ordering

Don't most (novice & intermediate) users work in full screen mode?
I don't know, do they?  Certainly not on platforms that don't have it. Many apps
(most?), such as Mozilla, do not open windows maximized by default, so even for
those users that do, it would be a choice after having been exposed to a layered
windowing system.  Utilities, dialogs and secondary windows never use the full
screen, but they do obey z-order layering, so it is a well-understood concept.
I don't think the five seconds of "exposure" before most users maximize a window
(permanently) is enough to adequately understand z-ordering. "Utilities, dialogs
and secondary windows" are rarely (if ever) tabbed between, thus they also do
not sufficiently convey the concept of z-ordering.

Users will understand (remember) what window/tab they worked in most *recently*.
As for novice and intermediate user behavior, it is widely different. You can't
assume that they all work in full-screen mode. The window size users choose
correlates to the current task being performed which may rely on the current
window/app but may involve multiple windows and multiple apps. Even novice users
learn about z-order very quickly because it maps to a real world experience as
Peter mentioned. Good designs build on what people already know. My question is
who is the target for this feature? I didn't think it was being positioned as a
novice feature. 

The ordering of the tabs appearing left to right provides a very strong cue to
users about their placement and expected behavior. Thus I think the current
behavior of displaying the tab to the left of the closed tab as new "current" is
logical, easily discoverable and quickly learnable. These principles far
outweigh any clever strategy that meets some folks' models of elegance. I
recommend sticking with the current implementation. 
How about a pref for this? Tabbed browsing already has its own section, so we
just need to add another checkbox:

[x] After closing a tab, focus the most recent one

Nonetheless, i think that most users would expect this behavior, since it would
make opening and closing links in new tabs parallel what happens when they open
and close links in new windows.
[ ] After closing a tab, focus the right most tab
[ ] After closing a tab, focus the tab to the left of the closed tab
[ ] After closing a tab, focus the most recently focused tab
[X] After closing a tab, focus the tab from which closed tab was originally opened

If we can't choose from all four above in prefs, then "summary" of this bug
should be the default behavior.

> "Good designs build on what people already know."

*After closing a tab, focus the most recently focused tab* is how EVERY
application on my work machine behaves.  It is how EVERY windowing desktop
environment I've used behaves.

I fail to see how one could claim that this is merely a "clever strategy" --
clever enough that every other UI implements it.  It makes no sense to call a
feature "easily discoverable and quickly learnable" when it goes against the
computing experience the user is already accustomed to.

Being able to map UI features to some real-world experience is not the ultimate
goal of UI design, in fact, some truly terrible interfaces have resulted from
this attitude.  The concept of ordering along the Z axis is not that strong in
most windowing systems.  It mostly relies on windows overlapping one another
rather than the other visual cues we have in real life.  Try doing funny things
like putting windows side by side or having one window overlap two others and
you'll find the concept erodes pretty quickly.

It was pointed out that one time this behavior doesn't map to an existing UI
experience is the concept of opening tabs in the background.  However, this
feature is off by default, so it doesn't seem unreasonable to me that a user
found this option, that user would be able to switch the "Tab Closing Behavior"
to "Next Tab Left" or "Next Tab Right".

Thanks.

Note 1: I tested this behavior on these windowing sytems around my office: MS
Win2K, KDE, Gnome, Solaris, and SCO desktops, and these MDI apps: MS Office, MS
Visual Studio, Lotus Notes, MicroEdge Visual Slick Edit.

Before you dismiss this bug, I suggest you take a poll of the applications you
use daily, and see if Mozilla isn't breaking with all the rest of them.


Notes 2: I'm questioning ideas here, not people.  I rant because I care.
All the examples you raised involved *windows* (as has been pointed out 
before). How many *tabbed* apps have you tried?

I just tried Lotus 1-2-3 where sheets are represented by tabs. If I delete the 
sheet/tab I'm on I go to the next sheet/tab to the *right*, not the previously 
viewed sheet (and not the one to the left).

Think of a hanging-file drawer or rolodex. If you pull out the file you're 
looking at you reveal the one immediately behind it. In our left-to-right 
culture that would typically have a tab to the right. The file drawer doesn't 
remember that you last looked at the Peterson file.

In any case, switching the direction from left to right would be pretty trivial 
I'm sure, but re-writing the code to include the concept of tabbing history 
just isn't in the cards given the minuscule benefit vs. the number of other 
serious bugs we've got.
Lotus Notes R5 uses tabs, and uses the "last-viewed" method (admittedly, Notes
isn't a great example of UI design otherwise, but I've never heard anyone
complain about the tabbed design).  Anyway, what's the difference between tabs
in Mozilla and the Windows taskbar with a bunch of maximized windows?  I can't
think of any, in fact, it's what I thought mozilla's tabs were supposed to be
emulating.  Not a file folder.  Do you normally read your documents as they sit
in a file folder?

But-- you're getting hung up on the real world.  A computer CAN remember that
you last looked at the Peterson file, and the main point I'm arguing is that
since this would be intuitive to any user (from prior UI experience), there's no
reason why the computer shouldn't remember.

Except of course that this is a low-priority bug, a fact which I can accept. 
But let's please not let this one go for good.
Switching from left to right would be a good start. Consider:

User opens Moz and goes to Google, submits search.

User opens first three search results in new tabs. So the tabs look like, from
left to right:

1. Google search results page
2. Google's first link (i.e. the one that is most relevant)
3. Google's second link (the second most relevant)
4. Google's third link

Now the user wants to look at these results, in order of relevance. So they
click tab #2, see that it's not relevant, and close it. Now they want to be
looking at tab #3. But Moz displays tab #1.

If the user closed tab #1, the problem would be solved. But then, if the first
three search results were no good, they have to submit the search all over again.


I go through this all the time -- with Google, Slashdot, Bugzilla, anything that
lists a bunch of stuff that i want to look at in a particular order.
That argument doesn't really apply, since fixing this bug also assumes that 
newly opened tabs (via open link in new tab) would be opened just to the right 
of the current tab instead of always being placed on the end.

Then you just move from right to left and naturally end up back at the tab 
that spawned all of the subtabs.

This is how Netcaptor (and incidentally how I implemented the behavior in 
Chimera) does it, and it works very well.
Hyatt: was that in response to my comment? I don't think we're disagreeing here. 

The core problem i want to solve is when you have a parent page that has a lot
of links that you want to open in a particular order and then view them in that
order by clicking the first one, reading it, closing it, and having focus sent
to the next one, while keeping the parent page open.

Anything that solves that problem will make me happy.
And with that, I think we've heard enough on this subject (close returning to
'parent' tab).  Some recent posters obviously haven't even read the previous
discussions, so this is clearly just wasting everyone's time.  Resolving as
wontfix, please take any further discussion to n.p.m.ui.  If someone wants to
open a bug to get the behavior Dave describes in comment #78, please do so.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
vrfy wontfix.

requests are / will be in seperate bugs, so as to avoid morphing this one.
Status: RESOLVED → VERIFIED
*** Bug 134539 has been marked as a duplicate of this bug. ***
*** Bug 134788 has been marked as a duplicate of this bug. ***
*** Bug 137203 has been marked as a duplicate of this bug. ***
*** Bug 138834 has been marked as a duplicate of this bug. ***
*** Bug 137047 has been marked as a duplicate of this bug. ***
*** Bug 141687 has been marked as a duplicate of this bug. ***
*** Bug 144208 has been marked as a duplicate of this bug. ***
FYI: Several of the bugs duped to this one are requesting that focus should be
returned to the _previously active_ tab rather than the _parent_ tab. In the
future, those should be duped to bug 144207 rather than this one. (Sorry for the
spam.)
Even though it is marked WONTFIX, I'd like to add to the debate the following:

1. In the tests debated in bug 144207, only one was browser and other internet 
applications seem not to have been considered. Considering Chatzilla (sorry) 
doesn't seem that much relevant, if mIRC is not considered.
mIRC behaviour is (as requested) focus on previously focused tab.

2. Why tabs should behave radically different then application windows regarding 
this issue? 

Both of these comments have already been addressed in previous discussions in
this bug, other bugs and on the newsgroups. Please read through existing
discussions so we don't have to start making FAQs for each bug.  1) Other
popular browser and other apps were considered and discussed.  mIRC is oviously
targeting very advanced users, and does many things that would not be
appropriate in a browser for mass consumption.  2) Tabs are not windows, in
particular there is no layering which makes their focus behavior visible and
predictable.
"Tabs are not windows, in particular there is no layering"

Tabs are a functional substitute for windows, regardless of the intent of the
Mozilla crafters for their use. 

Tabs have two layers, the active, and all other, evidenced by the tabs themselves.
I stand corrected, tabs have at most 2 layers. If we limited the user to two
tabs, we'd have a visible layering model. I'm not sure what you mean by
"functional substitute".  They can certainly be used as a substitute for
multiple windows, but that doesn't mean they need to adopt all the behaviors and
properties of windows.  If they did, we'd be right back at square one, with
slow, bloated tabs.
I also prefer to go to the "parent" when closing a tab.

This issue doesn't reach a consensus. Why don't do it a configurable option?.
Any of us can choose their prefered option and the programming assignment could
be done in a boring evening. What's the subject, then? :-???? A veto???
Don't bother, this bug is WONTFIX.  If a patch is attached, it will not get r=,
if checked in it will be backed out.
*** Bug 148099 has been marked as a duplicate of this bug. ***
*** Bug 149786 has been marked as a duplicate of this bug. ***
just filed the duplicate bug 149786.

i'm asking you to please REOPEN this one.

fix should be Z-ORDER, not PARENTAL order, and not the fix proposed
in comment #78.

as many users have explained, the current behaviour is "predictable"
(peter trudelle), but totally COUNTER-INTUITIVE. tabs are not windows,
but they are expected to be arranged not only on a x-, but also on
a z-axis. that's why you say you "bring them to front" or "open them
in the background". 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.

three ways of fixing this were proposed. switching back to a tab's
"parent tab" is neither the expected behaviour nor possible (see
comment #40). opening new tabs right of their "parent tab", as
chimera does (and as it was proposed in comment #78), is as counter-
intuitive as the current behaviour (for example, opening 3 new tabs
from a page will not arrange them 1-2-3, but 3-2-1) and does not
take into account that tabs are perceived as as objects on a z-axis.

the only argument against way 3 (a z-order for tabs, just like
z-ordering windows) was that when opening multiple tabs in the
background, closing one of them would always bring their "parent"
back to front, instead of the next background tab (see comment #54).
but this is exactly the current behaviour if you read and close them
chronologically, left to right, and can only be avoided by reading
and closing them right to left. an exception for such tabs ("when
closed, bring to front the tab right of it instead the one left of
it", see comment #48) would hardly be implementable. what would be
implementable is CLICKING ON THE FRONT-MOST TAB SENDS IT TO THE BACK
(so that even background tabs could be browsed in an intuitive order
after sending their parent to the back).

to sum up: REOPEN this bug, Z-ORDER tabs, implement sending active
tab to the back of the z-order by clicking on it.

this bug is about tabbed browsing in mozilla being counter-intuitive
(which it still is), and it has been closed for purely ideological
reasons.
It sounds like you want to reopen bug 144207, not this one.
I'll second the plea for reopening whatever bug number deals with tabbed 
window behaviour.

Tabs have obviously been copied from Opera functionality, but copied badly. 
Tabs have been _the_ major reason for a lot of people I know to switch to 
Opera, because you are able to make a 'breadth first' reading with it, just 
closing a tab brings you to the next _expected_ tabbed window.

The difference between Opera and Mozilla in its actual version is purely ...

                           _Intuition_   (with a capital I)

Just look at how many duplicates of this 'bug' have been opened.
Actually, tabs appeared in Mozilla builds before they did in Opera, and AFAIK
everyone copied the idea from NetCaptor, which has had them for years.  In any
case, what you are probably using in Opera are their MDI windows, which behave
as many people seem to want here, not their tabs, which behave exactly as ours
did until the focus on close reversed direction last week.  I don't think there
is an RFE bug on that, you might want to consider opening one, and referencing
it here.
Also consider mIRC behaviour as an example

Comment 98:
> the only argument against way 3 (a z-order for tabs, just like
> z-ordering windows) was that when opening multiple tabs in the
> background, closing one of them would always bring their "parent"
> back to front, instead of the next background tab (see comment #54).
> but this is exactly the current behaviour if you read and close them
> chronologically, left to right, and can only be avoided by reading
> and closing them right to left.

Mozilla's behavior has recently been changed to focus the tab to the right
instead of the one to the left when you close a tab. So what you describe is no
longer the current behavior.

> Also consider mIRC behaviour as an example

mIRC does not have tabs. It has MDI child windows.

Guys, what you are asking for is making Mozilla an MDI application. That is a
valid RFE, but it has *nothing* to do with tabs.

Besides, this bug is about returning focus to the parent tab. The bug about
giving tabs a z-order is bug 144207.
[OT] Perhaps a brief *explanation* and some *screenshots* showing the difference
between tabs and MDI would alleviate a lot of the confusion and misunderstanding.
MDI, for Mutiple Document Interface, refers to being able to view multiple
documents at once.  Having several Navigator windows open inside your window
manager so that each window has its contents visible is MDI.

Tabs allow one to switch between document windows, but only view one document at
a time.


IMO, one can view the tabbed interface as a subset of MDI.  Most MDIs allow the
user to maximize all windows and switch between them using what are essentially
tabs, or glorified radio buttons.

The most popular MDI is of course Microsoft Windows, which, even with all
windows maximized, uses ordering along the Z-axis ("return to last-viewed")
(#144207).  Since the common excuse around here is that we are designing for the
common users, not the elite few, should this not be the behavior we copy?  
No, because there is no ordering of tabs beyond a 2-level z-index, as is
discussed in bug 144207.  Please take such discussions to that bug, or better
yet to the newsgroups, as spam from wontfixed bugs just distracts from work on
bugs that need to be fixed.
i have slightly modified my proposal (implement z-order and add
"send tab to back" option to tab context menu) and taken it to
bug 144207 (comment eighteen), which i am asking to reopen.
*** Bug 152004 has been marked as a duplicate of this bug. ***
*** Bug 155914 has been marked as a duplicate of this bug. ***
Bug 155914 was a z-order request. Z-order requests should not get duped to this
bug. Probably bug 144207 is the best place to dupe z-order requests, although I
think bug 115234 never should have been duped to this in the first place and
would be the better place to dupe 155914 and other z-order requests.

We probably need a tracking bug for all the wontfixed requests to change the
current tab closing order. I've been collecting them in a spreadsheet, with 31
found so far and no attempt yet to count the votes from those who haven't file a
bug on their own or unvoted comments that left-to-right and right-to-left are
unacceptable.
*** Bug 167799 has been marked as a duplicate of this bug. ***
*** Bug 188702 has been marked as a duplicate of this bug. ***
Please re-open this bug.  There's a lot of controversy as to what should be
implemented.  Please just implement a number of them and let the user decide -
or create a framework that allows the user to write preference code that makes
as many of these options available.

There's been suggestions for a radio box.  Please implement it.

If there's any question of this, look at how many times this gets submitted as a
bug.  Obviously people believe that it should function differently - and they
believe it enough to get an account and learn how to make a submission.
Rudy: If you want this behaviour, install the Multizilla extension.
*** Bug 225556 has been marked as a duplicate of this bug. ***
*** Bug 231234 has been marked as a duplicate of this bug. ***
*** Bug 233107 has been marked as a duplicate of this bug. ***
*** Bug 240125 has been marked as a duplicate of this bug. ***
*** Bug 246055 has been marked as a duplicate of this bug. ***
please reopen, solution from comment #8 is the easiest one.

just make a douple linked list of tabs in the order they were activated.

*** Bug 248164 has been marked as a duplicate of this bug. ***
*** Bug 262480 has been marked as a duplicate of this bug. ***
*** Bug 269937 has been marked as a duplicate of this bug. ***
My bug was just dup'ed to this one.

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.

*** Bug 269937 has been marked as a duplicate of this bug. ***
*** Bug 270836 has been marked as a duplicate of this bug. ***
*** Bug 275006 has been marked as a duplicate of this bug. ***
(In reply to comment #72)
> How about a pref for this? Tabbed browsing already has its own section, so we
> just need to add another checkbox:
> 
> [x] After closing a tab, focus the most recent one
> 
> Nonetheless, i think that most users would expect this behavior, since it would
> make opening and closing links in new tabs parallel what happens when they open
> and close links in new windows.

The problem with stating that Windows' taskbar behavior is is how tabs in
Firefox should be has a flaw, in the case that the user opens Firefox tabs in
the background.  Sebastian hit on this very nicely.  

If, when opening a tab, the user has it come into the foreground, then if he
closes it immediately, then this is correct:  the close behavior should be like
Windows' close behavior and should go to last focused tab.  If he has it opened
into the foreground, but then he doesn't close it, and instead switches to
another tab, then, if he ever goes back to it, or if he closes any other tab,
the switching should become chronological again (to the right).  This whole
issue of switching back to the 'parent' tab should only occur when there is
immediate closure of a 'child' tab.  After any other switching, parentage should
be lost, and the only tab relationships should be chronologically visual. 

If, contrary to above, a user opens tabs in the background for later viewing,
close behavior should always go to the next one to it's right, because users who
open tabs in the background want to view these pages later in the chronological
order that he opened them in.  Also, there is no way for him to get away from
the current tab, e.g. he can't leave the one he has open, then switch to another
tab, and then continue going through the rest chronologically, because it keeps
jumping back to the first one (annoyingly).  

A new problem, which I refer to in bug 279574, is that in Single Window Mode,
Javascript and popup links that would normally open as new windows, open with
focus (in the foreground) as tabs.  But, all your middle clicked links can still
open in the background.  My solution there could also be applied here to middle
clicks that open in the foreground.
Rewording my fix for the other bug to apply here:

The solution to this bug is simply this: When closing a tab that has just been
opened into the foreground, such that no more tab switching has occured, return
to the originating tab.  If any other tab switching has occured after opening
this tab, even if you then later switch back to this tab, the closing behavior
should use the regular, move to the right, chronological behavior.  That is it.
 That fixes all arguments that I see mentioned here.  Are there any functional
problems with this?  

Yes, I am sure you could come with special cases where you would still want that
child tab to always go back to its parent, but that is a very special case, and
is not predictable or logical, especially since that parent tab might not even
be present anymore, once some more tab switching has occurred.
comment #128: "should become chronological again (to the right)"
comment #129: "use the regular, move to the right, chronological behavior."

I don't know why people tend to refer to "move to the right" as "chronological".
"Chrono" means "time" and "chrononological" means "in time order".

And that's how it should be: Ordered by Time: If a foreground tab is closed, not
the one to the right or left, not the one, from where the current tab was
opened, but *last foreground tab* should become visible.

This is the behaviour with windows (and I am not talking about Microsoft
Windows) in all window managers I've ever seen. 



(In reply to comment #130)
> comment #128: "should become chronological again (to the right)"
> comment #129: "use the regular, move to the right, chronological behavior."
> 
> I don't know why people tend to refer to "move to the right" as "chronological".
> "Chrono" means "time" and "chrononological" means "in time order".
> 
> And that's how it should be: Ordered by Time: If a foreground tab is closed, not
> the one to the right or left, not the one, from where the current tab was
> opened, but *last foreground tab* should become visible.
> 
> This is the behaviour with windows (and I am not talking about Microsoft
> Windows) in all window managers I've ever seen. 

Yeah, what people mean by "chronological" is how they were opened initially, not
how they have been focused since then.  Actually, moving to the next tab to the
right is a feature, not a bug.  It is very useful, because it allows you to open
a bunch of pages at once into tabs in the background to view later.  Thenyou can
 either close the current tab you are viewing or leave it for later, and then
methodically move through the rest of the tabs that you haven't viewed yet, in
the order you opened them.  Jumping  back to the previously focused tab each
time kills this ability.  This is a feature that is very useful in a browser,
but not something very useful in a windows environment.

However, the situation where you open something into the FOREGROUND, and then
close it IS different.  If any switching occurs after a tab is opened into the
foreground, then, when closing a tab, the browser should switch to the next one
to its right.  But, if no switching has occurred, then each tab closure should
take you to the previously focused tab.  And after you have closed all the
user-initiated tabs in this chain, THEN it should move to the one to its right.
 Did you read my solution above?  I think if you were able to try it, you might
like it.

In browsing, unless you immediately close a page that you just opened into the
foreground, you usually just want to go on to the next page to read.  People
will leave that original tab open to refer to for later, and then go through the
rest of the day's tabs.
(In reply to comment #131)
> 
> Yeah, what people mean by "chronological" is how they were opened initially, not
> how they have been focused since then.  

we are talking about "focusing" one tab after closing another.
Thus I am talking about the chronological order of focusing,
not the chronological order of creation of tabs


> Actually, moving to the next tab to the
> right is a feature, not a bug.  It is very useful, because it allows you to open
> a bunch of pages at once into tabs in the background

I agree with you that the expected behaviour might differ if you create tabs
into background. 


>  Did you read my solution above?

I assume you refer to Comment #129. Yes I did. And I completely disagree because
I think that focusing a tab should not be so complicated.


I think it is as follows. There are (at least) three (big) partys here:

1. some people want that the tab to the right (or left) of the closed tab is
focused. call this "to-the-right". this is the currently implemented behaviour.

2. some people want that the parent tab of the closed tab is opened, i.e., the
tab from which the closed tab was opened. They dont' care which tab is focussed
if no parent existed.
call this "parental-order"

3. some people want the tab last focused to be focused if a tab is closed.
call this "chronological-order" (chronological order of the focus)


I certainly belong to the third party. because that's what I _expect_ from the
tabs. Of course I learned how they behave. Still, the option 3 is the "most
natural" in my opinion.

But as somebody mentioned above, there are again and again dups of this bug.
People just expect the tabs to behave differently than they do at the moment.

I think that the best solution would be to implement all three of them and let
the user choose. But: Who shall do it? the bug is already marked as "VERIFIED
WONTFIX"
(In reply to comment #132)

Can you explain to me in more detail why it is so complcated?  I think it is
complicated only in the difficulty to put it into words.

Here is what I am proposing, in practice.  Say you have three tabs open, A, B, C:

1.)  While viewing A, you middle-click a link.  It opens in the foreground in a
new tab D.  You read from it what you want, and then close it.  It takes you
back to A. You then close A, and it takes you to B.

2.)  While viewing A, you middle-click a link.  It opens in the foreground in a
new tab D.  You read from it, notice a link within it you want to open, and
middle click that link.  It opens in the foreground in tab E.  You read from it,
and then close it.  It takes you back to D.  You read from it and close it.  It
takes you back to A.   You then close A, and it takes you to B.

3.)  While viewing A, you middle-click a link.  It opens in the forefround in a
new tab D.  You read from it, THEN DECIDE TO LEAVE IT OPEN FOR LATER.  So, you
click on tab B to continue going through the rest of your tabs that are open. 
You close B.  It then takes you to C.

What you are saying is that you want it to switch back to D in this case.  That
is counteractive behavior, because you just purposefully switched AWAY from D. 
The only reason you would want to switch back from tab B to tab D is if you were
comparing these two tabs, and in that case, you wouldn't have CLOSED B.

In other words, I can create a real-world scenario for why you wouldn't want it
to switch back to D.  Can you describe a scenario where you WOULD want this to
happen? Please give me a real-world scenario where my model wouldn't react as
would be most helpful, besides criticizing the method ITSELF for "being
complicated".
QA Contact: bugzilla → nobody
(In reply to comment #133)
> 
> Can you explain to me in more detail why it is so complcated? 

it's complicated because it behaves differently in different situations.
remember that a user doesn't have a description of what happens when and wants
to guess it from seeng at tha behaviour of the browser.

> Can you describe a scenario where you WOULD want this to
> happen? Please give me a real-world scenario where my model wouldn't react as
> would be most helpful, besides criticizing the method ITSELF for "being
> complicated".

sorry for not giving you an example. but you make an assumption that a user
opens B,C,D from A to read them later, then reads D and either closes it (or
opens some more tabs inbetween and closes them), returning to A (which would
happen in all 2. and 3. from comment #132 as well. Or, the user desides to keep
D and to continue reading the (not-yet-read) tabs A and B.

but a user opening tabs in a foreground wouln't open B,C,D to read them all
later, since this would mean:
 open B
 switch to A
 open C
 switch to A
 open D
 continue with your example.
If I would use the tabs as you describe, I guess I would prefer to open them in
background too.

Well, I think I'll give you an example:

suppose you have tabs A,..,G all containing information you already read and
decided to keep. you are at F and decide that you probably don't need B any
more. you switch to B to check if you are right and close it. You certainly
don't want to go to C.

*** Bug 292829 has been marked as a duplicate of this bug. ***
Based on recent user research and an increased amount of focus on introducing
novice users to tabbed browsing behaviour, I'm reopening this bug and
recommending that Firefox consider using an interaction model as proposed in
comment 128.

A user feedback study has shown that there are two models for browsing with
tabs. Under the first model, opening a document in a new tab is done in order to
investigate a related resource without losing one's place in the original
document, or to deal with an incoming request (from another application, IM,
etc). The other model is where tabs are treated as a mechanism to "queue"
resources to be investigated later.

The best rule to support both of these models is:

If tab has opened with focus,
  and the user has not switched to another tab,
  then when the tab is closed, return to the parent.

(Reopening, with the adequate deference and respect to the original resolution)
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Hardware: PC → All
Target Milestone: mozilla1.2alpha → ---
Sorry, it has been a while.  I re-read over the bug comments here, and this that
you mention is the browsing logic that I had previously been pushing to
implement to “patch” the current method, but there are still some people that
want a different method.

What you and I are asking for makes what we CURRENTLY have better, and does not
infringe upon the group that wants an overhaul, because they browse using
different settings anyway.
 
Let me now respond back to Sergei Haller, who is in the group of people asking
for a change in the behavior when middle clicked links are opened as tabs in the
foreground, so that when closed the browser takes the user to the previously
focused tab, but also that so that it follows chronologically how you have
clicked on the TABS themselves. I personally think that their idea is a good one
in theory, but that basing behavior on the second part, TAB clicks, is hard to
implement successfully, and that part of it can be very frustrating to the user.
 I have listed my ideas about this below, but the important distinction here is
that what we are asking for is based only off of link clicks WITHOUT tab clicks
in between.  What they are asking for ALSO deals with tab clicks.

(In reply to comment #134)
> (In reply to comment #133)
> > 
> > Can you explain to me in more detail why it is so complicated? 
> 
> it's complicated because it behaves differently in different situations.

Adding this little bit of "complication" is not a bad thing, IF, and I believe
it does, follow what user want the browser to always do in a certain situations,
and if it is easily predictable.  It then only makes the user experience more
logical, not more complicated.  It behaves in this one specific type of
situation differently, and only because this is what most users expect it to do.
 Different situations sometimes SHOULD be dealt with differently.

 I think the issue you might have with this is that pressuring (if that is even
possible) Mozilla to implement it, it would not be moving Firefox towards what
you are wanting.  Contrary to this, I think there should be an option for what
you want, but that what you want isn’t even directly related to my issue, and it
needs to be specifically defined and explained this way, to avoid confusion. 
Both can actually work hand in hand, depending on how the user sets the options.
 There are certain cases where we can make the CURRENT system better, and we
should be careful with trying to overhaul the whole thing at once.  THAT is what
would confuse the user.  This needs to be well thought out.

> > Please give me a real-world scenario where my model wouldn't react as
> > would be most helpful, besides criticizing the method ITSELF for "being
> > complicated".
> 
> sorry for not giving you an example. but you make an assumption that a user
> opens B,C,D from A to read them later, then reads D and either closes it (or
> opens some more tabs inbetween and closes them), returning to A (which would
> happen in all 2. and 3. from comment #132 as well. Or, the user desides to keep
> D and to continue reading the (not-yet-read) tabs A and B.
> 
> but a user opening tabs in a foreground wouln't open B,C,D to read them all
> later, since this would mean:
>  open B
>  switch to A
>  open C
>  switch to A
>  open D
>  continue with your example.
> If I would use the tabs as you describe, I guess I would prefer to open them in
> background too.

> Well, I think I'll give you an example:
> 
> suppose you have tabs A,..,G all containing information you already read and
> decided to keep. you are at F and decide that you probably don't need B any
> more. you switch to B to check if you are right and close it. You certainly
> don't want to go to C.
> 

I see what you are saying here now, and you, in a way, have made the situation
clearer for me.  I was making an assumption.  Let me clarify.

My case refers generally to when opening tabs initially into the background,
yours refers to when opening all of those tabs initially into the foreground. 
Also, yours refers to behavior that occurs AFTER a user initiated tab switch. 
That is what is creating our difference of opinion; simply an argument over
unrelated issues. 

The problem here is that while my method of browsing is fairly well dealt with
the current system, with only one minor complaint, yours is not dealt with
adequately at all.

With regards to opening links from pages into the background (one of my
concerns), the current tab browsing behavior should stay the way it is.  Another
case of where it should stay the same is when opening a folder full of bookmarks
into the background.  For instance, I daily open a whole bunch of tabs into the
background by middle clicking onto a folder.  I then go through those pages and
open links contained within THEM into the background by middle clicking.  The
current method, does all that I need with this.  It is only when, in the course
of browsing, that I open something external into the window as a tab that
becomes focused (Single Window Mode), when a popup link is diverted into tab in
foreground (Single Window Mode again) or when a bookmark is middle clicked into
the foreground (if I have that option set that way) where there becomes an
issue.  (see Bug 279574)
 If anything, this BACKS UP your assumption that a change is needed regarding
things that are opened into the foreground, because all of these special cases
refer to this type of situation..  In all of these cases, if you immediately
close the tab, it should take you back to the previously focused tab.  I can
only imagine that if you also open your normal middle-clicked links into the
foreground that it could be even more of an issue.  

Here is the problem, though.   While it is easy for the browser to base its
behavior off of LINKS that are clicked into the foreground, It is hard to come
up with logic to decide what exactly needs to happen once the user has clicked
away onto TABS, because the browser cannot then easily predict that user’s
intentions.  For all it knows, these tabs have been clicked randomly, with no
specific user intent.

So, I agree that tabs that are opened into the foreground, and then closed after
NO TAB SWITCHING has occurred, that it should go back to the previously focused
tab.  100 percent, always.  But, what I find to be hard to agree upon is what
the browser should do after tab switching has occurred, and I find that your
solution to this problem is tedious to the user.

You left your own example open-ended, and did not explain what you think the
browser SHOULD do in this particular case, so I am going to assume that you want
the browser to make a logical decision here, based on how you previously clicked
on the other tabs.  This is getting into an area that I think we should leave
alone, because I think IT will ultimately just confuse the user. 

But let me ask you a couple questions, giving you the benefit of the doubt.  My
opinion here is that the tab it displays next MIGHT AS WELL be tab C, because it
really doesn’t matter which tab it goes to next when you state that you have
read all of the tabs already.  If you happen to be comparing tabs, the browser
certainly can’t predict your comparison behavior.  What else would you be doing
if you aren’t comparing?  Well, you could be bookmaking these tabs individually,
or you could be closing them out one by one, right?

If you are bookmaking the tabs one by one, and then closing them, it is annoying
to keep going back to F, because you have either already bookmarked it, or it
isn’t one that you want to bookmark.
 With regards to closing them out, what you are saying that you want is for you
to click on B and close it, and it takes you back to F, then if you click on C
and close it and it takes you back to F, etc.  You don’t need to be going back
to F each time if you are closing the windows out, because that is just
annoying, since obviously you want to leave F open.
Now if you are comparing F to the other tabs and then closing them one by one,
then you really don’t need it to be going back to F each time.  You should be
able to remember the contents of F over more than one other tab viewing.  If you
cannot, and you are actually comparing something specific like comparing wording
of different pages or looking at slight differences in pictures, in other words,
where you have to go back and forth a lot, you definitely won’t be closing out
tab B anytime soon, and when you finally do, it isn’t going to matter anymore
which tab comes into focus next. Once to this point, you are dealing with
diminishing returns to expect the browser to do exactly what you want it to, and
anyway, this in and of itself is a special case that your proposal does not do a
very good of job solving in the first place.

An easy solution to your problem situation of closing tabs out would be to
implement the ability to right-click and close tabs out WITHOUT FOCUSING THEM. 
That would be a separate feature request, however.

So, on the surface it may seem logical to you to for it to go back to F, but
what really is your purpose here?  What is it that you are trying to do with the
browser?  It seems to me that something along the lines of some advanced tab
hierarchy and tab movement and organization seems to be more up your alley then
continually returning to the same tab over and over. You say that "you certainly
don't want to go to C", but you don’t explain why or what would really
practically be any better.  Remember as well that it was your own active CHOICE
to click on tab B and then close it.  The browser didn’t know why you clicked on
B.  So it is in THESE types of situations that the browser should do something
standard and predictable, e.g. go to the next tab to the right, which in this
case is tab C.  

It is hard to see how to do what you are asking for and make it globally
applicable.  The browser should allow for passive browsing, not browsing where
your brain has to actively remember the order you clicked on tabs previously in
order for you to predict future behavior. This, along with the loop that keeps
taking one back to the previous tab annoyingly are the problems to solve with
trying to implement any kind of “tab click memory”.

Again, I believe these are unrelated issues.  Having the browser base behavior
off of link clicking, which is basically what our one specific case describes,
is MUCH easier and simplified than basing behavior off of how tabs have been
clicked.  This is because the restrictions of the foreground and background
options allow us to treat each foreground situation the same and each background
situation the same, as long as code can be implemented to make sure that no
other tab has been clicked on in between.  As soon as the user clicks away to
another tab, that is it, end of story, back to the “to the right” method.

Your proposal to have an option where the browser will always go to a previously
focused tab, if there is one, is very simplistic, but not in a good way.  It
would benefit from some more logic on the browser’s part, but coming up with a
good logic base here is difficult, and ultimately, I think it would lead to
complication, which is what we are trying to avoid?  I think your proposal
should be more thought out first.

In my opinion, there should be two bugs, one referring to tabbed browsing
behavior relating to foreground and background focusing middle link clicks, and
one referring to tabbed browsing behavior relating to remembering tab clicks. 
From what I understand, your way, once all previously clicked tabs have been
exhausted (closed), reverts to the standard "to the right" behavior anyway, so
both yours and my idea would work together, if done properly.

Here is an idea on tab click memory. Maybe instead of making another separate
option, we should implement a button that is on the taskbar or tab bar that you
can temporarily or continuously leave depressed.  It would enable or disable a
tab memory function.  Starting at the point that you click to depress that
button, the browser will then retain memory of your tab clicks.  At any time
that you want the browser to forget this, and go back to just moving to the
right, you can undepress this button.  And it would not interfere with my
proposal, because no tab click would have occurred in between to create a conflict.

This would also allow for it to be a conscious user-initiated action, therefore
the user would then pay attention from that point on, and would not be confused.
Then, once the user wants to GET OUT OF LOOP of previously clicked tabs that it
creates, and move on to the others that have not been read, he can simply
undepress the button.  There would be a need for an option to either have the
button default as depressed or undepressed at startup, of course.

TAB CLICK-initiated tab focusing cannot be easily predicted from, and as such,
the behavior should follow the default (eg, go to the next tab to the right
after closure). 

LINK CLICK-initiated tab focusing CAN be easily predicted from, and should fall
back to the previous tab in the chain of only link clicks.

One simple way to implement the change in forground-opened tabs is to place them
to the left of the tab that opened them.  That would make the parent tab next in
line using the current rule of movement on tab closing.

It might seem a little strange to put the new tab in that position, but think
about it this way:  you click on a link that opens a new forground tab, that
seems to move the current tab to a background position after the current tab
(which is really the newly-opened tab in the same visible position as the
previous foreground tab).  I think it just might work, and be very easy for the
user to understand.
(In reply to comment #137)
Dude, you write _books_ for bugzilla comments.

Anyway, it's been pointed out to me that I shouldn't be opening this on core, as
that's really SM's domain. I'm switching back to WONTFIX, and will consider
opening a bug purely on Firefox for this, since the usability study I was
talking about was done with Firefox and had Firefox users in mind.

(Apologies to the component owner)
Status: REOPENED → RESOLVED
Closed: 22 years ago → 19 years ago
Resolution: --- → WONTFIX
Ha, yeah, sometimes I just get into it.  This bug is at the top of my list.  I'd
been sitting here with a cold and nothing else to do, so I put it down in
writing as detailed as possible.  

This bug needs some direction, someone to actually decide what it is focusing
on, instead of all these diverging opinions.  I think I spelled out a good
starting point for categorizing the differing viewpoints contained here.  There
is enough information here to do this right.  I am against fragmentation, but I
do think in this case it just needs to be split up and organized into a couple
of separate bug reports, one related implementing into Firefox some sort of
memory option or button that remembers tab clicks, and one related to tabs
coming into focus through link clicks.  These are separate issues, and should be
separate bugs.  

A third bug report might even need to be created because there are those that
want implementation of some sort of more sophisticated tab hierarchy
enhancements, and neither of the above issues really gets deep into the issue of
implementing real, linked  parent-child tab relationships, regardless of the
fact that this bug has the word “parent” in the title.

The big boys have simply thrown all of these seemingly related tab issues into
one big pot, and referred all duplicates back to it, and left it alone to fall
into disrepair.

Yes, I did not realize we didn't have a separate bug report for Firefox, either.
 I can create one if you wouldn’t prefer doing it.  I will make sure to be
concise. :)  By the way, if you didn't make it all the way through my "novel",
my listing of Bug 279574 is a Firefox bug, and is very similar to this bug's
situation, except smaller in scope, as it just applies the model you speak of to
diverted windows in Single Window Mode.  It might not even be practical to have
that bug report anymore, IF we can get the ball moving on this one.

(In reply to comment #139)
> Anyway, it's been pointed out to me that I shouldn't be opening this on core, as
> that's really SM's domain.

Core is Core (shared), if it were a purely seamonkey issue it would be in the
Mozilla Application Suite product. There are currently two physical incarnations
of the tabbed browser widget kept in sync (mostly), but that's a botch that will
be fixed when seamonkey eventually moves over to using "toolkit" rather than
xpfe/global.

If you're planning on fixing this behavior this bug is as good as any, and both
versions of tabbrowser.xml should work the same.
Product: Core → SeaMonkey
(In reply to comment #20)
> ... the currently implemented behavior (close causes switch to tab on left,
> if it exists, else tab on right) is about as simple and predictable as we could
> get.

VERIFIED WONTFIX
Status: RESOLVED → VERIFIED
Sorry for the addition to the long comment list, but I think this bug should be re-opened. This is essentially what I posted in the Thunderbird thread (originally thinking that it was for Firefox too; my bad):

The current behavior in Firefox 12 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.

Here's my take:
{ // Definitions
Let T be the closing tab.
Let A be some ordering of the tabs, either:
a. by first opened time (when it appeared in the tab bar)
b. by last navigation initiation time (when the page started loading)
c. by last viewed time (as in the ctrlTab previews)
Let O(X) be the owner of tab X.
}
Method of focusing tab after closing T:
1. Always switch to the tab on the *left* of T.
2. Switch to first unclosed tab in A.
5. Switch to O(T). If there isn't any owner, switch to first unclosed tab in A.
6. Assuming the owner relationships form a tree, with child-nodes ordered by A, switch to the last tab in the subtree rooted at T, or if there is none, switch to that of O(T).
  * - you recursively take the last sibling if it exists.

I prefer method 2 with order c, which is currently made available in Tab Mix Plus, under "Events > Tab Closing > Closing Current Tab". I think it should be transferred from TMP to the Firefox main branch.
Apologies for the same mistake again. I didn't see "SeaMonkey" right at the top... but it was linked from a similar *Firefox* bug! I give up trying to find a duplicate bug; will be opening a new one.
You need to log in before you can comment on or make changes to this bug.