Closed Bug 178556 Opened 22 years ago Closed 21 years ago

Ctrl+Tab and Ctrl+Shift+Tab should use stack ordering

Categories

(Firefox :: General, enhancement)

Product:
Firefox
Component:
General
Platform:
x86
All
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: theodore_m1, Assigned: bugzilla)

References

Details

When you press ALT+TAB in Windows to switch between running programs, stack
ordering is used to switch between the propgrams, rather than simply rotating
through them. The user can switch between the same two programs quickly by
repeatedly pressing ALT-TAB. Phoenix should do this with it's tabbed windows and
the CTRL-TAB keystroke. 

To see what I mean, in Windows, open up three applications. Then,
-hold down ALT
-press TAB
-release ALT
-repeat
You'll switch between two of the three apps.

Do the same in Phoenix with CTRL-TAB, and you'll rotate through all the tabs.
So you mean pressing Ctrl+Tab four times in a sequence would make Phoenix jump
back and forth between two opened tabs? Why on earth would you want that
behavior when the current behavior is the default in virtually every program?

Suggesting WONTFIX.
David: pressing (Alt+Tab) 4 times switches back and forth between the focused
window and the most recently used window.  Holding Alt and pressing Tab 4 times
switches to the fourth most recently used window.

This bug is the same bug 144207, "After closing a tab, focus should shift to the
most recently focused tab" (wontfix), except that this bug is filed on Phoenix.
I don't think this is a good idea. At present, the order in which tabs will be
cycled is readily apparent from their position on the tab bar. Not so with stack
ordering, unless Phoenix reorders the position on the tab bar every time a new
tab is opened, which is not going to happen. This is not a problem with
Windows/KDE when Alt+Tabbing as the positions are reordered "behind the scenes"
as it were.

Seconding David Tenser's WONTFIX suggestion.

Nevertheless, I'll confirm it for developer review

-->Confirming for developer review
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Visual Studio 6 does something like this.  I can't stand it.  I never know which
window is going to come up next when I press Ctrl+Tab.
C-S-tab would be unnecessary then.  Alså, C-arrowleft/right should inherit
todays behaviour of C-tab/C-S-tab.

With "stack ordering" "windows alike tab" is meant.
*** Bug 201706 has been marked as a duplicate of this bug. ***
*** Bug 203486 has been marked as a duplicate of this bug. ***
Dean (#4), it's easy to know which window is going to come up next when I press 
Ctrl+Tab if you pay attention to what window had focus previously.

David said in #1: "Why on earth would you want that behavior when the current 
behavior is the default in virtually every program?"

It makes perfect sense when you want to work with two tabs out of the whole set 
of open tabs. For example, one tab show a list of messages in a discussion 
board, and you open another tab that would show one of messages on that board, 
and you are reading it now. Now, for some reason you need to quickly look at 
the message list. Pressing Ctrl-Tab would accomplish that, provided that the 
window with the message list had focus most recently (which did in my example). 
But without this feature, you will have to cycle through all open tabs (if you 
only have two or three tabs open, it's not problem for you, and you shouldn't 
even comment on this issue). And if you want to get back to the message window, 
you will have to cycle through all open tabs again, instead of just pressing 
Ctrl-Tab (if Phoenix behaved as this bug suggests it should). I frequently have 
5 to 10 tabs open, and when I am doing research or downloading images from 
thumbnails galleries, I sometimes I have as many as 20 or so tabs open. If I 
want to quickly get back to a tab that just had focus, I am out of luck with 
Phoenix, so I have to use Opera for serious work (and Opera also has this 
miracle feature -- it can search for whole words in a page :) ), or IE (for 
other capabilities). With Phoenix I have to cycle through all the tabs to get 
to one that just had focus.

I have a suggestion. It's obvious that different people require different 
behaviors in this regard. Then how about implementing both behaviors and being 
able to configure this aspect? We've got to work with users. I personally don't 
see anything in Phoenix that other browsers can't do, and if Phoenix developers 
are going to satisfy only their desires, then...

I forgot to add that Opera (both 6.x and 7.x) and Ultraedit behave the way this 
bug describes.
Summary: CTRL+TAB and CTRL+SHIFT+TAB should use stack ordering → Ctrl+Tab and Ctrl+Shift+Tab should use stack ordering
UltraEdit is a tool made by a programmer for programmers.  There are many
interface problems with it, so I wouldn't hold it up as an example.

If you want to work with only two tabs, use Ctrl+Tab and Ctrl+Shift+Tab.  I
highly doubt this will be changed.  And no, there won't be a pref for changing this.
At least UltraEdit is made for OTHER programmers (read: with other people in
mind). Phoenix, on the other hand, seems to be made by programmers for
themselves. No wonder there are people willing to spend money for Opera, even
though there several free browsers available.

You can always find problems in anything. I find UltraEdit very convenient.

Your other comment about using Ctrl+Tab and Ctrl+Shift+Tab if I want to work
with only two tabs only shows that you really don't understand the issue. Try
doing what you recommend, and you will hopefully see that Phoenix doesn't work
that way. I'll give you a hint: using Ctrl+Tab and Ctrl+Shift+Tab will move you
from adjacent window to another. This is not what I described in my example.
Please read it more closely. If the example is still unclear, I will give you
another one, or maybe somebody else will chime in with a better explanation and
justification.
If you want to work with two tabs the best policy at present is open them
successively so they are beside one another on the tab bar. The next best is to
install TBE and use its ability to move tabs to place the two you want beside
each other.

The difficulty with stack ordering is if you're an insane user of tabs like
myself with a dozen or so tabs open at once it becomes frustrating trying to
figure out which one is going to crop up next. Read comment #3 again to see why
this really isn't a good idea.

Perhaps a better idea than full stack ordering is to have a short cut, maybe one
of the Function buttons or something like Ctrl[or Alt]+Backspace, to return to
the previous active tab. Just the previous active tab, not the rest of tab
history. That would seem to address the most likely use of stack ordering
without completely destroying the utility of the tab bar as a visual reference
by fully implementing stack ordering in place of the current system.
Ctrl+Backspace would work for me.
Actually, Ctrl+Backspace is used to delete a word. So, Alt+Backspace would be a
better choice. Interestingly, Alt+Backspace currently does some funky text deletion.
Phoenix isn't made for any programmers, it's made for end-users.  That's where
Mozilla went wrong, and why there's a pref for every conceivable action and
function.  I really think this fringe behavior is better suited to an extension.
 Perhaps the author of TBE would be willing to add it.
Tabbrowser Extensions has now implemented this behavior (use Alt+Shift+LeftArrow).
Replying to Dean's "That's where Mozilla went wrong, and why there's a pref for
every conceivable action and function"

IMO, adding preferences for various actions and functions to software would be
user-unfriendly if configuring were forced upon the users. As far as I know,
this is not true for Mozilla. A novice or uncaring user would work with default
settings out-of-the-box, but a more sofisticated user has an ability to
customize the browser. Would you call a "loaded" top of the line Lexus or
Mercedes Benz more or less user friendly than, say, base level Toyota Corolla?
This was debated when tabs were first added to mozilla. The current behavior was
consensus. TBE implements this, advanced users can use it. Strongly recommending
WONTFIX.
Please stop for a moment.

On initially reading this bug, I felt that the reporter was being dealt with
very unfairly. Investigating bug 144207 and those it references, I can see that
this is a long, drawn out issue. Saying the same things over and over is not fun.

Think for a second, though, about _why_ this issue keeps coming up. After
countless arguments, discussions, and duplicate bugs, there are still more
people confused enough by the current behavior to register a bugzilla account
and file it as a bug. 


__Comment 2 states that this is the same issue as before, only with Firebird.

Very well, let's consider it on those grounds. Last time I checked, the idea
behind Firebird was to create a browser that _most_people_would_use, since the
seamonkey suite was (for various reasons) not such a beast. Specifically, at
least according to the discussion I've read, Firebird targets IE users. 

IE (and Navigator before it) uses different windows for different pages. Nearly
everyone looks at more than one page at a time. Nearly everyone uses IE (or
Navigator). THUS: Nearly everyone is used to a stack behavior for switching
between web pages. 


__Comment 4 in bug 144207 describes a usage pattern supporting the current behavior.

Immediately upon reading it, I thought: wow, I never thought of doing that. It
seems very much an uncommon behavior, designed specifically for repetitive
tasks. In about half a year of using Firebird, I have never once taken advantage
of the _order_ in which tabs are opened. This, usually, is because they end up
pretty random during my (and I suspect most people's) normal browsing.


__Another argument (bug 144207, comment 11) for the current behavior is that a
stacking order relies on the user to remember which tab is where in her history.

And, as we all know, we should never rely on a user's memory. Right now,
however, we're relying on the user to remember what ORDER they opened the tabs
in (huh? that's even worse!), or else expecting them to look at the tab bar to
know where they want to go next. With that sort of interruption, they may as
well switch with the mouse (as I usually end up doing. sigh.)

On the other hand, most windows users have been trained to retain in their mind
a history of at least the last 2 or 3 things they were doing. I can't count the
number of times I've been surprised to get a seemingly random page on hitting
Ctrl-Tab, while expecting the most recently focused one.


__Another big argument: There is no visual representation of a stacked system,
while there IS a visual of the linear arrangement. 

As stated in bug 144207, however, there are apparently other applications that
maintain a linear list of items and yet still allow stack-based switching. The
windows taskbar is a great example of this. I believe Opera counts as well. And,
of course, let me reiterate that IE users, new to the whole tab-based browsing
thing, already expect a stack-based behavior. Keep in mind that the majority of
new mozilla users previously used IE. 

Also on that note, even if we change the behavior currently used, we don't have
to abandon our ability (Ian Hickson, users fitting his usage pattern; see above)
to take advantage of the linearity of our tabs. Ctrl-left and Ctrl-right seem
perfect ways of moving between tabs to me, and don't apparently have a use at at
the moment, except in text entry areas. I could be wrong.


_Finally.

In closing, though, I'm not sure why I should even have to discuss most of the
above. Especially with the new "Let's make a browser for the public!" attitude.
It's obvious that a terrible lot of people are confused by the current pattern.
As we get more converts and have proportionally fewer geeks around, even more
people will be. This might be a good time to take a hint from the persistence of
this argument and consider the alternate behavior.

Thanks, and apologies for the essay.
-> WONTFIX

Its been debated before, and decided.  I don't think there's any new arguments
for this that haven't been decided against before.  Most users are visual users,
who look at the tab bar, especially with favicons, and decide what tab they
want.  The current behaviour works in a different way.  TBE does implement this
for those who want it, otherwise current behaviour stands.

Regarding the last comment, given that a grand total of four people have
commented in this or its dupes, and there has been a grand total of 5 votes in
10 months, I don't see a huge outcry for this functionality.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
I fail to see where adding the _option_ to use stack ordering hinders anything 
anywhere. Please clarify.
verified wontfix
Status: RESOLVED → VERIFIED
As to the number of people:

I've only discovered this in bugzilla recently, but taking only references from
this bug, I found long discussions in bug 144207 and 105722 about a similar area
of behavior. A shorter discussion (and some bad ideas) were in 131037.
Apparently this has been discussed over and over for 2 years now. The wealth of
duplicate bugs on all of these is pretty large. I think it's fair to say that
it's not a small issue, nor important to a tiny subset of users.

As for votes: from what I have heard, they generally don't have much attention
paid to them, and so people rarely use them. I could be wrong; I'm kinda new at
this. 

I can't argue with a verified wontfix, I guess. I just don't understand the
fanatical opposition to stack ordering. There seems to be no interest in even
allowing this to be customizable. Since there are obviously two mindsets for
browsing at work here... that seems strange.
It is customizable.  Get Tabbrowser Extensions.
One shouldn't have to get a (huge) extension devoted to offering every
conceivable tabbed-browsing option to get basic functionality. 

As there is a lack of consensus in this or any other bug about how this should
behave, what makes the most sense to me is to implement both behaviors*. Even in
this bug, the most anti-stack I've seen, the split is close to 50/50. 

Implementing this would require minimal effort (heck, I'll do it!), remove no
existing functionality, add no significant bloat, please half the user base, and
displease no one*. No discussion of this has ever reached its conclusion. This
one wasn't even given a chance. So, since we're tired of it, we'll stick with
the same problematic behavior. ... I don't get it.



* for the record, let me make clear the suggestion: implement stack ordering,
but leave Ctrl-Tab/Ctrl-Shift-Tab and Ctrl-PgUp/Ctrl-PgDn as is. Create a pref
that would switch Ctrl-Tab/Ctrl-Shift-Tab to stack ordering. That's it. We don't
need dialog boxes, radio buttons, 4 behavior options for what to do when you
close a tab or anything... this is Firebird, after all.
I'll say "Thank you!" if you do it.
*** Bug 233931 has been marked as a duplicate of this bug. ***
(In reply to comment #25)
I don't think it's as simple as you think. As you can read in my duplicate bug
233931, the challenge is with what to do when opening tabs in the background. I
think you could have a policy of ctrl+tab showing the most recently
not-yet-viewed opened-in-background tab and then once you've gone through all
the not-yet-viewed tabs start switching between windows in most recently-viewed
stack order, but that might be confusing.
Actually, I think that doesn't really complicate things:

My intuition would be to consider tabs opened in the background to be at the
bottom of the recent-viewing stack, in the order you opened them. (You've never
viewed them, after all...)

As for the usage pattern you're describing, (open google, open useful results in
the background, browse one by one,) [1] Ctrl-PgDn would still work for this, if
stack-ordering were on, and [2] if this is your usage pattern, you'd probably
just stick with LTR-ordering anyway.

Incidentally, the way these tab switching works now is slowly altering my usage
pattern into the one described above, like it or not. Oh well.
*** Bug 255507 has been marked as a duplicate of this bug. ***
There's now a 4KB extension called LastTab that changes the Ctrl[+Shift]+Tab
behavior to what was requested here.  I haven't tried it out but it sounds like
it's a better implementation than TBE, for a couple of reasons:

1. It provides both forwards and backwards navigation.
2. It doesn't add a new keyboard shortcut, it uses the existing Ctrl+Tab and
Ctrl+Shift+Tab (and I think PgUp/PgDn) shortcuts.

http://update.mozilla.org/extensions/moreinfo.php?id=112
*** Bug 264322 has been marked as a duplicate of this bug. ***
*** Bug 266458 has been marked as a duplicate of this bug. ***
*** Bug 287631 has been marked as a duplicate of this bug. ***
Keyboard navigation between multiple programs is unnecessarily difficult
currently (on MS-Windows, a mix of ALT-TAB, and multiple CTRL-TABs to switch
between a couple of web pages and another application). This could be reduced if
either this or a (non-hidden) preference for windowed browsing was implemented.
However, both options are WONTFIX.

*** Bug 292176 has been marked as a duplicate of this bug. ***
*** Bug 315055 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> Visual Studio 6 does something like this.  I can't stand it.  I never know
> which
> window is going to come up next when I press Ctrl+Tab.

That's why it presents a list of tabs on a popup dialog.
This is plain wrong. We already have keybindings for Tab at right and Taba t left: they are Ctrl+PageDown and Ctrl+PageUp.
So it makes sense to have keybindings for "cycle to previously visited Tab" and "cycle to next visited Tab".

At least, please give us a setting to configure this, instead of forcing a person to pollute Firefox with an extension installation.
Why on earth would I want to switch to the next tab in the tab bar? I don't care in what order they are aligned there. When at all I switch tabs, I do so to look up something in a related tab. There's two related tabs that I want to compare. I need to get fast access to those, and not *all* other tabs. Even what I move those tabs next to each other, I can only switch forward quickly. When I want to go back again, I need to press the Tab key (while holding Ctrl) as many times as I have open tabs, minus one. That's a huge productivity killer. I honest believe that those people (including Mozilla devs) who strongly reject the MRU behaviour really don't use that hotkey at all.

All operating systems do that with Alt+Tab. Guess why? Because recency and locality is what matters, not some artificial sequence order. That doesn't matter at all. Nobody wants that. Yet you deny fixing this issue in Firefox.

There have been numerous addons to provide that feature, and they've been very successful. Unfortunately, all of them broke a few years ago when Firefox has made some breaking change. I've tried to make my own addon for that but the Firefox addon SDK isn't suitable for this kind of tasks. It works for a while but currently it fails after some usage.

The only place where such a basic behaviour could ever be robustly added is the core. C'mon, you don't even have to use it. Add a switch for that, maybe just a hidden pref key. The actual behaviour is not much more than a few short lines of code. The only thing that needs to be touched in the code is the decision function that selects the next tab. And a bit of Ctrl press/release state handling. I can't do otherwise than to consider the Mozilla devs the greatest ignorants if they don't even consider to try to do it. After all, you're ignoring masses of feedback from your users. All of this feedback is negative. If you don't make this browser for your users, why does it still exist? I don't need to accuse you, all other users already do that.
Oh I forgot: "Most users are visual users, looking at the tab bar." You didn't notice that most of these users are mouse users as well, they don't even know that Ctrl+Tab does anything? Don't build the feature for those who don't need it. Build it for those who care! Again, ignorants. Proved.
You need to log in before you can comment on or make changes to this bug.