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 ***

v

Bug 105722 is a WONTFIX; bug 144207 is a WONTFIX; this bug is separate from them and still needs to be discussed. Reopening.

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.

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

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

Checked in.

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.

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. ***