Closed Bug 123563 Opened 23 years ago Closed 22 years ago

Please make tabs close in left-to-right, not right-to-left order

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: anthony, Assigned: jag+mozilla)

References

Details

Attachments

(2 files)

Move to the right when the active tab is closed
762 bytes, patch
caillon
: review+
hewitt
: superreview+
Details | Diff | Splinter Review
Fix tunnel vision :-)
419 bytes, patch
Details | Diff | Splinter Review 
Tabs would be more useful if they closed in FIFO, not LIFO order. Consider
opening a bunch of messages from a mailing list archive, etc. If they close LIFO
(like they do now), you have to manually click each tab to read the messages in
order. If they closed FIFO, then closing the tab would get the next messages.

Also, earlier tabs are more likely to be loaded.
I agree. This is how I was expecting tabs to work the first time I used them,
and its the way that still makes more sense.
dup of 105722 "Closing tabs should return to 'parent' tab." where there are a
lot of comments about how should the tabs be closed.

*** This bug has been marked as a duplicate of 105722 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
Bug 105722 is a WONTFIX; bug 144207 is a WONTFIX; this bug is separate from them
and still needs to be discussed. Reopening.
Blocks: 101794
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Please note that current behavior is not as simple as described, nor would the
proposed behavior, since it must take some edge cases into consideration.  Also,
IMO the proposed behavior only makes sense in combination with another proposal
for new tabs to open to the immediate right of the current tab, rather than at
the right end.
->1.2, for consideration in the next release cycle.
Target Milestone: --- → mozilla1.2alpha
This is a very common scenario for me: You have three tabs open; we'll call them
1, 2 and 3. The three tabs each contains three links which you want to open in
new tabs; we'll call them 1A, 1B, 1C, 2A, 2B, 2C, 3A, 3B and 3C.

The current behavior:
You click on each of the links in tab 1. They open at the end of the tab bar.
You do the same for tab 2 and 3. Tab bar now looks like this:
1 2 3 1A 1B 1C 2A 2B 2C 3A 3B 3C
Tabs 1A and 1B have finished loading; the rest are still loading. So you focus
tab 1A to read it. When you're finished, you close it. Focus goes to tab 3, so
you have to focus 1B manually. When you close 1B, focus again goes to 3, so you
have to focus 1C manually. However, at this point the remaining 6 tabs have
finished loading, so you can choose to focus the last one instead (so you won't
have to switch tabs each time you close one), but then you'll have to read the
links in reversed order. Conclusion: The current behavior is bad for this scenario.

The behavior proposed in this bug:
You click on each of the links in tab 1. They open at the end of the tab bar.
You do the same for tab 2 and 3. Tab bar now looks like this:
1 2 3 1A 1B 1C 2A 2B 2C 3A 3B 3C
Tabs 1A and 1B have finished loading; the rest are still loading. So you focus
tab 1A to read it. When you're finished, you close it. Focus goes to tab 1B, and
you read that. This continues until you have read tab C3, and focus goes back to
tab 3. Conclusion: The behavior proposed in this bug would be good for this
scenario.

The behavior proposed in comment 5:
You click on each of the links in tab 1. They open to the immediate right of tab
1. You do the same for tab 2 and 3. Tab bar now looks like this:
1 1C 1B 1A 2 2C 2B 2A 3 3C 3B 3A
Tabs 1A and 1B have finished loading; the rest are still loading. So you focus
tab 1A to read it. When you're finished, you close it. Focus goes to tab 2. You
must then focus tab 1B manually, and after that focus tab 1C manually. In fact,
each of the nine new tabs must be focused manually if you want to read the links
in the right order. You can't even have them focus an unread tab by reading them
in the reverse order, like you can with the current behavior; there would always
be a tab 2 and tab 3 to skip through. Conclusion: The behavior proposed in
comment 5 would be as bad if not worse than the current behavior, IMO.

IMO opening tabs on the immediate right of the current tab doesn't make any sense.
In practice, my usage patterns as described in bug 144207 comment 4 mean that 
sometimes right to left is better, and sometimes left to right is better. 
However, I could easily change my usage patterns so that (with this bug fixed) 
I would have to manualy focus fewer tabs than possible with the current 
behaviour. So this suggestion makes sense to me. Patches welcome. :-)
There are many scenarios possible, and it makes little sense to start off by
listing one, then encouraging patches.  We need to get wider feedback from
actual target users, and consider all of the common usage cases before making
such changes.  
BTW, I think you're right about the 'open immediate right' behavior not making
much sense in combination with this. I think I was associating them because they
both addressed some of the concerns about closing behavior, but I should not
have linked them together here.  Pardon my cerebral flatulence...
trudelle: agreed on both counts.
I'm now very convinced that the improvement suggested in this bug is in fact an
improvement. I think we should go for it.
I suspect you may be right, but I'm cautious about introducing such changes
after so much testing, especially the RCs and the NS beta. At best, a lot of
current users will wind up deleting a lot of tabs they didn't intend to. Jag may
have a few minutes to try this out as an option on the trunk though...
Oh, I definitely am not suggesting we change it on the branch, no.

I hear Netscape did some usability testing recently; was this issue examined?
Comment on attachment 85254 [details] [diff] [review]
Move to the right when the active tab is closed

r=caillon
Attachment #85254 - Flags: review+
Hixie: no, it didn't examine this, and IIRC, users didn't comment on the order.
 We plan to have further in-depth testing.

Jag- Weren't you going to implement this new behavior based on a pref? I think
we should be careful not to just change such fundamental behavior suddenly on
people, it should be opt-in until we have evidence that it is better.
But that evidence will not come if this is an opt-in change. If people use the
trunk builds they should be prepared for sudden changes like this. Just check it
in and let's get some feedback! :o) It can always be backed out easily if the
feedback turns out to be negative...
I would be extremely opposed to adding a pref (even a hidden pref) for such a
one line change. We have enough bloat as it is. We do not need more prefs.
Comment on attachment 85254 [details] [diff] [review]
Move to the right when the active tab is closed

sr=hewitt
Attachment #85254 - Flags: superreview+
Checked in.
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Keywords: mozilla1.0.1, nsbeta1
Resolution: --- → FIXED
Most of the tabbed browsing behaviors are pref-based, and get plenty of testing
by the people that want them. You guys would scream loudly if a feature you used
and liked was suddenly changed and you found out by deleting the wrong tabs. 
This was intended to be a way to prototype this behavior, not a decision to
suddenly change the default. Bloat is not an issue, because we don't need to
continue supporting the non-default behavior if the default behavior satisfies
enough of the target market.  I suspect you'd be the first to object if we took
away one of the tabbed browsing prefs you use.
> Most of the tabbed browsing behaviors are pref-based

No, four are. And we've been fighting against adding more prefs. I'd rather have
the old (IMHO broken) behaviour than the behaviour on a pref. And this has been
made very clear in many Tabbed Browser bugs.


> and get plenty of testing by the people that want them. You guys would scream 
> loudly if a feature you used and liked was suddenly changed and you found out 
> by deleting the wrong tabs. 

This feature won't change which tabs are deleted, only which are focussed. (So
it is only an issue if you are closing multiple tabs in a row.)

And yes, I have been screaming about losing tabs -- see the bug about the
bookmark groups causing dataloss.


> This was intended to be a way to prototype this behavior

That's what the trunk is for. We'll get feedback, and if the feedback is
negative (ignoring comments from those who are just unexpectedly hit by the
change, of course) then we can change it back.


> Bloat is not an issue, because we don't need to continue supporting the 
> non-default behavior if the default behavior satisfies enough of the target 
> market.

I am sure you are as aware as I am of how hard it is to get prefs removed from
Mozilla once they are added. And if you don't believe me, see about:config.


> I suspect you'd be the first to object if we took away one of the tabbed 
> browsing prefs you use.

I would probably be the last to object. IMHO the first two prefs should be
removed and defaulted to checked, and the last two merged and renamed "use tabs
instead of windows". Them we can remove an entire pref panel, increasing the
usability of the prefs panel by an order of magnitude.


VERIFIED FIXED on the trunk.
Status: RESOLVED → VERIFIED
Hixie, you know my position on quoting at length in bugs: time to take it to the
newsgroups.  The trunk is not the place to randomly change default behaviors,
and this change will result in people deleting tabs unintentionally.  We don't
make usability decisions based on what *you* like any more than we do based on
what *I* like.  We have a huge group of target users to consider, and the
mozilla participants are an extremely small and unrepresentative sample of them.
> Hixie, you know my position on quoting at length in bugs: time to take it to 
> the newsgroups.

And I'm sure you know mine -- if it's relevant to the bug, then Bugzilla is the
best forum. :-)


> The trunk is not the place to randomly change default behaviors,

Actually, the trunk is _exactly_ the place for well-planned changes to default
behaviours. We do this regularly as a way of testing the effects of changes.


> and this change will result in people deleting tabs unintentionally.

Trunk users take much greater risks.


> We don't make usability decisions based on what *you* like any more than we do 
> based on what *I* like. 

I am waiting for a usability study. In the meantime, the trunk is a good place
to test the reaction to the change.

What _should_ we be basing this decision on?


> We have a huge group of target users to consider, and the mozilla participants
> are an extremely small and unrepresentative sample of them.

Unless Netscape is planning a PR2, I don't see any other way of testing this on
more users than those who will download the trunk or 1.1.
If you quote everything, each bug and notification is twice the length it needs
to be.  This is *not* a well-planned change, we had a usability study that
showed no problems with delete behavior, so there was no reason to change a
default behavior.  Netscape is not planning to take random changes to default
behaviors after the beta.
Although I can agree with some the things in comment 6, I still think that it's
common practise to activate the tab on the left of the closed tab. But since the
guys in charge here decided that activating the tab to the right is how it
should be, I think there should be a pref for this. Despite comment 18.

I'm sure at least one person will use the leftside option (that's me!).
Peter: What happens on the Mozilla 1.0 and Netscape 7.x branches are separate
issues unrelated to what happens to the trunk and unrelated to this bug.

David: I used to be a "to the left" user as well; I recommend giving the "to the
right" behaviour a go. In my experience today, it makes life easier. If it turns
out the majority of users (determined preferably by a usability study; as Peter
said, Bugzilla commenters users are not a representative sample) prefer the old
behaviour then we can change it back.

Either way, though, there should not be a pref.
To prove that feedback doesn't only come from the trunk: I just applied this
patch to my branch build, and I'm loving it already. 
Took me all of one minute to unlearn the routine of opening links in the 'wrong'
order if I wanted to read several in order. This way makes for far more natural
(and efficient!) browsing.
comment 6 describes the usefulness of this behaviour, but it goes further, since
you often open additional links from just opened tabs. Working from right to
left as I did with the old behaviour, you'd still have to manually focus after
working your way through the originally opened tabs; now that is no longer
necessary.
This is very much better than the prior behavior. Too bad it isn't in the
release branch.

A fix for bug 131037 would be better still.

> Either way, though, there should not be a pref.

Perhaps it's new-tab-in-background users who perfer the new behaviour?
In which case we can reuse the pref...
Build 2002060704

Although this bug is closed, please reconsider creating a pref for this. I find
the to-the-right behaviour to be very anti-intuitive. It is common gui behaviour
to jump to the left sibling or parent upon closing an item, not only in tabbed
applications, but also in a normal list where one item is removed. Focus always
jumps to the previous item. Currently Mozilla is the only application I know of
that does it the other way. It's driving me nuts :-(
I haven't tried the new closing method yet, but I don't agree that the usual GUI
behavior is to jump to the parent.

The best example I can think of is in a listbox where you can add and remove
items. When you remove the selected item, you don't expect the selection to be
deleted and then moved up one. You expect the selected item to be deleted and
the next item in the list to be selected.
True, but the choice between parent or previous sibling depends upon the gui
element. If you delete e.g. an item from a tree, most applications will jump to
the parent, if you delete an item from a (tab)list, most applications will jump
to the previous sibling. Both Delphi and KDevelop e.g. have tabs and jump to the
previous sibling.
To Comment 28 (Ian): 
Why shouldn't there be a pref for this? There's even a pref for making the URI
selected or not when clicking on the Address field in Mozilla. That's something
that I think fewer users will ever care about than this one. Could you give us a
good reason not to put in a pref for this?

It could default to the "right" (current) option, but there should definitely be
a pref for it.
The pref for the autocomplete widget should be removed.
There is a simple reason for the "whether to make the URI" selected pref.  It
actually has two default values.  It's true by default on MacOS and Windows,
false on Linux.  This is because those are the behaviors that match user
expectations on those platforms.  This pref, on the other hand, is not likely to
have a platform-specific default value, now is it?

Let's not confuse things we do internally via prefs (instead of just having
"#ifdef XP_WIN"/"#ifdef XP_MAC", etc, sections of the code or reinventing the
wheel and having a "per-platform default" database) with prefs we provide for
user convenience.
*** Bug 159862 has been marked as a duplicate of this bug. ***
*** Bug 164809 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: