Closed Bug 445499 Opened 17 years ago Closed 17 years ago

Allow Ctrl+Tab preview to display in tab bar order

Categories

(Firefox :: Tabbed Browser, enhancement)

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

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.1b1

People

(Reporter: nightstalkerz, Unassigned)

References

(
URL
)

Details

(Whiteboard: use browser.ctrlTab.recentlyUsedLimit=0)

Attachments

(1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008071603 Minefield/3.1a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008071603 Minefield/3.1a1pre Ctrl+Tab preview only dispays in recently visited order. Having a preference to display in tab bar order would make more sense to users. Reproducible: Always Steps to Reproduce: 1. Press Ctrl + Tab 2. 3. Actual Results: Ctrl+Tab preview is shown in recently visited order. Expected Results: Ctrl+Tab is shown as user wants (recently visited or tab bar order).
Blocks: 395980
We could add a hidden pref for this, or leave it to an extension.
A hidden pref would make this usable IMO.
Attached patch First hack at doing this (obsolete) — — Splinter Review
This is a) my first piece of Firefox (or any other mozilla code) hacking and b) untested (haven't quite gone through everything I'd need to do to get this into my running browser), so *hopefully* it'll work. It adds a pref browser.ctrlTab.nonMRUTabSorting which when set should keep the tabs in the order they're shown in the bar,
Comment on attachment 329880 [details] [diff] [review] First hack at doing this Ctrl+Tab will always lead to the first tab this way, and tab reordering (e.g. drag and drop) isn't taken care of either. Unless it's to your joy, don't bother about a new patch, as I already have working code for this.
I would like this to be the default behavior, with MRU as pref. I don't know anything about what most users do. But I know that this "feature" is contradicting to the way I use tabs. I don't remember what tabs I most recently used. Or when I used a tab I need now. Being forced into this is not a "Good Thing". I know you are going to say that I can use ctrl-pgup/pgdn, but that means I need to use a different hand. Too much hand movement (from mouse to keyboard e.g.) might result in injuries. Just my 0,2€
I do think having the option to cycle through tabs in order is important. Both modes of switching work well, but for different kinds of tasks. As I see it, the recently-used version is excellent when you're working intensely with two or three tabs, and the version that goes in order allows for excellent preview of content. Definitely let's allow for both modes of use.
I think I'm leaning towards fixing bug 445476 but not this one. Immediate switching seems to be more straightforward than previews if the tab bar order is used.
Fixing that bug is also good. It shouldn't take more than a few lines of code at the start to check for the preference before assigning the ctrl + tab keys.
OS: Windows Vista → All
Hardware: PC → All
Bug 445476 is fixed now. Wontfixing this one as explained in comment 8.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Depends on: 445476
Resolution: --- → WONTFIX
Dao - I'm not sure I see the rationale for the wontfix here. I think the issue is that this has been an established key command for tab order. Immediate switching may be more efficient for some users, but not necessarily all
Ok, I think immediate switching is really more efficient for *most* users, but let's reopen this bug as an independent enhancement request.
No longer blocks: 395980
Status: RESOLVED → UNCONFIRMED
No longer depends on: 445476
Resolution: WONTFIX → ---
Version: unspecified → Trunk
Keywords: uiwanted
IMO a lot of people will be bothered about the new way of switching between the tabs. Personally I was also confused why it only switches between the two recent tabs when hitting Ctrl+Tab twice in sequence. I think that anyone has to adapt himself in using this new feature. It's the same behavior as switching between different applications. It will just take a bit. Lets confirm it for now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #13) > IMO a lot of people will be bothered about the new way of switching between the > tabs. This is, again, bug 445476, which gives you exactly the old way.
(In reply to comment #14) > (In reply to comment #13) > > IMO a lot of people will be bothered about the new way of switching between the > > tabs. > > This is, again, bug 445476, which gives you exactly the old way. Dao, sorry if it wasn't clear enough. I talked about the MRU tabs.
Me too. Bug 445476 added a pref to disable the preview panel together with MRU ordering.
A bunch of users want the preview panel with the ordering of the tab bar. In other words, want a way to disable the MRU but still have the preview that shows the tabs in the order that are on the tab bar. If the MRU way is so great, the tab bar would reorder itself ;) Just being a smartass trying to make a point.
URL: http://forums.mozillazine.org/viewtop...
Keywords: ue
I'd go as far as to say that switching in order should be the default behavior for Ctrl-Tab. The more I think about this feature, the more I think that the behavior of switching tabs in order should be the same action by hitting Ctrl-Tab as before, but with the added enhancement of seeing thumbnails. The recent switching can be an option and may work well for some users, but we have no evidence that this would work best for most users. What concerns me most about this not being default is that we're changing a known key command. It's a good rule of thumb to avoid changing known key commands if possible, because it is such a learned behavior and effects directly how efficiently users can work. Ctrl-Tab has been in place for years, and certainly people are used to its "cycle-through-tabs" behavior. I expect this will lead to experienced users to simply disable the new Ctrl-Tab. What are people's thoughts on this?
Same thoughts as 18, I thought it was a bug before reading in there that they were sorted by recently visited. Order should be or have an option to be: Current tab open is the center tab in the preview and then placed as the toolbar has them. If the user presses ctrl+tab and releases the keys right away, the same functionality we are all accustomed to is kept, going to the next tab.
(In reply to comment #18) > I'd go as far as to say that switching in order should be the default behavior > for Ctrl-Tab. The more I think about this feature, the more I think that the > behavior of switching tabs in order should be the same action by hitting > Ctrl-Tab as before, but with the added enhancement of seeing thumbnails. The > recent switching can be an option and may work well for some users, but we have > no evidence that this would work best for most users. I'm afraid asking for evidence won't come a long way. We have no evidence that the tab bar order works best for most users, and we have no evidence that thumbnails are useful when using the tab bar order. There's circumstantial evidence, though, with the Alt+Tab behavior on all popular operating systems. I can't think of any application that does what this bug asks for. > this will lead to experienced users to simply disable the new Ctrl-Tab. I'm totally fine with this.
(In reply to comment #20) > I'm afraid asking for evidence won't come a long way. We have no evidence that > the tab bar order works best for most users, and we have no evidence that > thumbnails are useful when using the tab bar order. So what are you basing your decision on that the MRU is the best way? > There's circumstantial evidence, though, with the Alt+Tab behavior on all > popular operating systems. I can't think of any application that does what this > bug asks for. > > this will lead to experienced users to simply disable the new Ctrl-Tab. > I'm totally fine with this. Well I'm not along with others. I want the previews and eye candy along with tabs in order that they are on the tab bar. I don't want to disable this and go back to the no preview just because I don't like the ordering. As is right now feels like Firefox is randomly picking which tab it wants to show me...which is stupid UE design if you ask me. And sorry, I'm not trying to knock you on this by calling it stupid. It just needs some more thought and less stuburness. You gotta think about how most users are going to think this is supposed to work.
I agree with comment #18. Ctrl + Tab is like a standard key command when using tabs just like Ctrl + S to save files. Changing the way it works will break for most users. I assume that the users who use Ctrl + Tab are experienced whilst the inexperienced ones do not know about it so it breaks functionality for the users who actually use it. There should be 3 preferences for this behaviour: 1. Disable completely (old behaviour) 2. Tab bar order with previews 3. MRU order with previews Dao, do you use the new MRU function or have you disabled it?
(In reply to comment #21) > (In reply to comment #20) > > I'm afraid asking for evidence won't come a long way. We have no evidence that > > the tab bar order works best for most users, and we have no evidence that > > thumbnails are useful when using the tab bar order. > So what are you basing your decision on that the MRU is the best way? Circumstantial evidence and personal experience / belief. There are also supporting anecdotal reports, but such feedback is hardly more useful than random people who are cc'd to this bug saying that they agree with comment 18; it's biased and can't be translated to trends and statistics. (In reply to comment #22) > I assume that the users who use Ctrl + Tab are experienced whilst the > inexperienced ones do not know about it so it breaks functionality for the > users who actually use it. That's possible, although there are also users who did use the old Ctrl+Tab and welcome the change. Now what if that change opens the way to inexperienced users getting used to Ctrl+Tab? After all MRU is a natural order and known from window managers, so there's a chance that we're not breaking their assumptions. Can we expect some (not all) of the experienced users to pay for this? > Dao, do you use the new MRU function Of course I do.
(In reply to comment #23) > (In reply to comment #21) > > (In reply to comment #20) > > > I'm afraid asking for evidence won't come a long way. We have no evidence that > > > the tab bar order works best for most users, and we have no evidence that > > > thumbnails are useful when using the tab bar order. > > So what are you basing your decision on that the MRU is the best way? > Circumstantial evidence and personal experience / belief. There are also > supporting anecdotal reports, but such feedback is hardly more useful than > random people who are cc'd to this bug saying that they agree with comment 18; > it's biased and can't be translated to trends and statistics. I'm just trying to figure out exactly what made you think that breaking a set way of switching tabs with the old ctrl+tab behavior is for the good. The users then understood exactly which tab was going to get focus when they hit ctrl+tab. Now that is broken and the users will get some random tab and will have to hit ctrl+tab more times then needed or just abandon there once shortcut and be irritated. I just don't understand why you are breaking the old behavior when there was nothing wrong with it in the past. And why you feel that focusing the most recently use tab is better then focusing a tab that was open before that one or even 20 tabs before that one. Might as well reorder the tab bar based on most recently used then also since you suggest this way is far superior.
(In reply to comment #23) > (In reply to comment #21) > > (In reply to comment #20) > > > I'm afraid asking for evidence won't come a long way. We have no evidence that > > > the tab bar order works best for most users, and we have no evidence that > > > thumbnails are useful when using the tab bar order. > > So what are you basing your decision on that the MRU is the best way? > > Circumstantial evidence and personal experience / belief. There are also > supporting anecdotal reports, but such feedback is hardly more useful than > random people who are cc'd to this bug saying that they agree with comment 18; > it's biased and can't be translated to trends and statistics. > What sort of evidence? Also, personal experience only applies to you, not the millions of other users.
(In reply to comment #23) > (In reply to comment #21) > > So what are you basing your decision on that the MRU is the best way? > Circumstantial evidence and personal experience / belief. There are also > supporting anecdotal reports, but such feedback is hardly more useful than > random people who are cc'd to this bug saying that they agree with comment 18; > it's biased and can't be translated to trends and statistics. Might want to read through the 80 comments here then...http://jboriss.wordpress.com/2008/07/16/control-tab-a-new-feature-for-firefox/
My personal view on this is that it is likely that far more users (both Firefox users and in general) have tried alt-tab and command-tab in their OS, than control-tab in Firefox. Therefor we will get a consistency win with adapting to the OS behavior, even though this will break the people who currently rely on the existing behavior of control-tab in Firefox.
(In reply to comment #27) > My personal view on this is that it is likely that far more users (both Firefox > users and in general) have tried alt-tab and command-tab in their OS, than > control-tab in Firefox. Therefor we will get a consistency win with adapting > to the OS behavior, even though this will break the people who currently rely > on the existing behavior of control-tab in Firefox. Can you think of any sane way of letting the user know what the order is so people won't be confused on why it seems so random? I can't think of anything at all that wouldn't be a distraction or make the panel ugly but figure you might be able to think up something.
(In reply to comment #27) > My personal view on this is that it is likely that far more users (both Firefox > users and in general) have tried alt-tab and command-tab in their OS, than > control-tab in Firefox. Therefor we will get a consistency win with adapting > to the OS behavior, even though this will break the people who currently rely > on the existing behavior of control-tab in Firefox. > I'm sure of that as well but the MRU order applies to windows, tab bar order applies to tabs within the windows. It's like filling in a form. You wouldn't expect tab to take you to the last edited field. Also Atl+Tab show more than 3 previews properly (not sure about Command+Tab but I will assume the same). (In reply to comment #20) >> this will lead to experienced users to simply disable the new Ctrl-Tab. > >I'm totally fine with this. If experienced users disable this and new users don't use it or can't find it, it there any point of implementing it?
Depends on: 450743
Hey - I made a blog post recommending some fixes to Ctrl+Tab here: http://jboriss.wordpress.com/2008/08/20/tabs-want-to-be-seen/. I think showing all tabs rather than just three, we'll take care of both the tab order and frequently used order. The design of showing all tabs, but in frequently used order, means that switching back to a tab is still a quick keystroke. But, this way, the user can still visually navigate the rest of their tabs. This also opens us up to changes such as being able to search tabs in the future. I believe users that wouldn't use the current design of Ctrl+Tab would use this because it supports more use cases than just flipping back and forth. I'd love to hear people's thoughts on this.
Two problems with that: 1. Usability with many tabs. Operating systems don't have to optimize this stuff for more than 10, maybe 15 windows, but we have to. With 20, 40 or 100 tabs, you either have to make the previews smaller (the "all tabs" panel does this) or add vertical scrolling. Both would be counterproductive for finding any tab or even a recently selected tab. The current Ctrl+Tab tries to escape this problem by supporting only the recently selected case. The other part is handled by the "all tabs" panel, where the search field helps managing lots of tabs. Besides, you can easily tab through 5 windows serially, but you don't want to do this for several dozen tabs. The current Ctrl+Tab discourages you from that, which I think is beneficial (as long as we offer the "all tabs" panel). 2. Performance. If there are many tabs, opening the "all tabs" panel from the Ctrl+Tab extension takes significantly more time than the Ctrk+Tab panel, which is bad for a shortcut that you expect to react fast.
This is great work Boriss, I like how you have merged the two use cases (quickly returning to the most recently used tab vs. invoking the UI to select something farther back in the MRU order). Some other thoughts: -it seems like we should add a very slight delay for displaying the UI like apple does, so when you command-tab very quickly between two apps you don't see the UI quickly appear and disappear (this happens on Windows). -I wonder if focusing more on the upper left corner of the page would make the thumbnails easier to view, instead of downsizing the entire page.
>Besides, you can easily tab through 5 windows serially, but you don't want to >do this for several dozen tabs. I agree that you wouldn't want to keep hitting the tab key to get to the window that you want farther back in the most recently used order, but I can see people using the mouse to select an item once the control-tab window is invoked. >Operating systems don't have to optimize this >stuff for more than 10, maybe 15 windows, but we have to. some possible solutions: -introduce a higher cap (like 10 or 15) -make the thumbnails in the first row larger, and subsequent rows smaller >2. Performance. If there are many tabs, opening the "all tabs" panel from the >Ctrl+Tab extension takes significantly more time than the Ctrk+Tab panel, which >is bad for a shortcut that you expect to react fast. Is there any way to draw the subsequent rows of thumbnails after the first row so that the user can interact with the interface before it is finished displaying? For the very quick case of just returning to the last tab you were on, we probably shouldn't be displaying the window at all (you release they keys before a small timer finishes).
(In reply to comment #34) > I agree that you wouldn't want to keep hitting the tab key to get to the window > that you want farther back in the most recently used order, but I can see > people using the mouse to select an item once the control-tab window is > invoked. Pressing Ctrl, hitting Tab, using the mouse to select a preview while keeping Ctrl pressed -- this seems awkward as a primary way to navigate. Supporting mouse clicks during Ctrl+Tab can't be more than a nice to have, imho. Win XP doesn't have this for Alt+Tab, by the way. For the "all tabs" panel it's of course a key feature. > >Operating systems don't have to optimize this > >stuff for more than 10, maybe 15 windows, but we have to. > > some possible solutions: > -introduce a higher cap (like 10 or 15) > -make the thumbnails in the first row larger, and subsequent rows smaller There's an assumption that the user is more interested in the first 10(?) tabs, right? If true, the subsequent rows are mostly noise that could be avoided. If false, the usability problem applies to the subsequent rows. The result is something that handles no case optimally. > >2. Performance. If there are many tabs, opening the "all tabs" panel from the > >Ctrl+Tab extension takes significantly more time than the Ctrk+Tab panel, which > >is bad for a shortcut that you expect to react fast. > > Is there any way to draw the subsequent rows of thumbnails after the first row > so that the user can interact with the interface before it is finished > displaying? I tried to display the previews asynchronously, which was very annoying because it reduced the perceived performance (i.e. it took longer to render all previews). You also can't interact smoothly during that time, as each preview still needs its CPU cycles.
>Pressing Ctrl, hitting Tab, using the mouse to select a preview while keeping >Ctrl pressed -- this seems awkward as a primary way to navigate. I totally agree this is an awkward way to intentionally navigate, the use case I am imagining though is that you expect a tab to be very recently used, but then it turns out that it is farther back than you expected but you still need to get to it. >There's an assumption that the user is more interested in the first 10(?) tabs, >right? If true, the subsequent rows are mostly noise that could be avoided. Yeah, I think I would put the number around 7 >If false, the usability problem applies to the subsequent rows. The result is >something that handles no case optimally. In an ideal world the user would know if the tab was recently used or not, and then choose the most optimal UI. I'm worried that often users are not 100% sure when they go into an interface like this, and that we should probably be able to gracefully degrade. Just to throw ideas out there, what if the 8th item in control-tab was a large version of the all-tabs icon, which when selected loaded the all-tabs panel?
(In reply to comment #36) > Just to throw ideas out there, what if the 8th item in control-tab was a large > version of the all-tabs icon, which when selected loaded the all-tabs panel? I think I'd like that, as it seems to solve all mentioned problems. Would you limit the Ctrl+Tab panel to these 8 items or continue with the remaining tabs when the all-tabs icon is skipped?
>Yeah, I think I would put the number around 7 Hey Alex - why seven? >(Dao's comments on displaying everything) I agree that we face some challenges for optimization here, but I don't think that simply not supporting all-tabs view is a solution rather than avoiding the issue. As long as we can keep the speed up, this is exactly the same functionality as MRU with three but with the added option of browsing for other tabs. That's why I think this could be a valid option - it supports both usage models. As for displaying too many items and no longer being able to make any out - perhaps there is a way to do scrolling so that it is not awkward. Perhaps a click to an edge brings up a new plate of tabs. I do think there's several ways this can be designed and I'm sketching some of them out though. For what will land in 3.1 though, just starting with showing all tabs may be an acceptable way. I've been trying out your own "show all" method, Dao, and was shocked to be able to display 3000 tabs (good work!) and still be able to make light details on them. So is it more not being able to distinguish tabs, or slowing down the system that concerns you? Also, I've made a blog post with a sketch of what OSX's Control Tab could look like if we went for "display all tabs." This is different from the last one because I mocked up exactly what I think 3.1 could use rather than the idealized "exactly like OSX" model from the last post. http://jboriss.wordpress.com/2008/08/22/tab-view-vs-application-view/
(In reply to comment #38) > As for displaying too many items and no longer being able to make any out - > perhaps there is a way to do scrolling so that it is not awkward. Perhaps a > click to an edge brings up a new plate of tabs. I do think there's several > ways this can be designed and I'm sketching some of them out though. For what > will land in 3.1 though, just starting with showing all tabs may be an > acceptable way. I've been trying out your own "show all" method, Dao, and was > shocked to be able to display 3000 tabs (good work!) and still be able to make > light details on them. So is it more not being able to distinguish tabs, or > slowing down the system that concerns you? Your goal is to quickly find and select a certain tab (even if it's not a recently used one, which means you might not be able to visualize the tab accurately) rather than telling two random tabs apart. The former needs the latter but eventually it's a more complex task, depending on how many tabs you have. Grouping the tabs helps if the desired tab happens to be on the first plate, otherwise it's hardly an improvement. I really don't see a way to make this work. The user can't search while pressing the Ctrl key, and anything that /requires/ the mouse to use Ctrl+Tab (a keyboard shortcut) efficiently seems like a failure.
>Hey Alex - why seven? I was thinking about two things, the fact that in control-tab on Vista applications wrap around to the second row at 7 items (and this seems to be intentional), and Miller's article "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information." However, giving that article a quick re-read, it really has to do with much more short term information storage (like someone reading a telephone number to you) than keeping a mental model most recently used tabs. So, I really don't have a very sound argument beyond Microsoft probably did a study and made an intentional choice, and 3 feels like too few and 10 too many.
Sorry, meant alt-tab above One quick comment about the visual design I think it is important that anything that closes on the release of keyboard shortcuts (like control-tab) should use the lighter grey background on OS X (matching command-tab) since this references another interface that is only modal by holding a key. Interfaces that close on mouse click outside of the window (bookmark panel, all tabs) should match the darker preview HUD style appearance, since these windows also dismiss on a mouseclick outside of the window. Kind of subtle, but I think it will help users understand ahead of time what to expect when they are interacting with these things.
(In reply to comment #39) > (In reply to comment #38) > > As for displaying too many items and no longer being able to make any out - > > perhaps there is a way to do scrolling so that it is not awkward. Perhaps a > > click to an edge brings up a new plate of tabs. I do think there's several > > ways this can be designed and I'm sketching some of them out though. For what > > will land in 3.1 though, just starting with showing all tabs may be an > > acceptable way. I've been trying out your own "show all" method, Dao, and was > > shocked to be able to display 3000 tabs (good work!) and still be able to make > > light details on them. So is it more not being able to distinguish tabs, or > > slowing down the system that concerns you? > > Your goal is to quickly find and select a certain tab (even if it's not a > recently used one, which means you might not be able to visualize the tab > accurately) rather than telling two random tabs apart. The former needs the > latter but eventually it's a more complex task, depending on how many tabs you > have. Grouping the tabs helps if the desired tab happens to be on the first > plate, otherwise it's hardly an improvement. > I really don't see a way to make this work. The user can't search while > pressing the Ctrl key, and anything that /requires/ the mouse to use Ctrl+Tab > (a keyboard shortcut) efficiently seems like a failure. What we could do is not require the user to hold down Control, but rather have the window by semi-permanent. So it would be summoned with a keystroke such as ctrl-tab, but a release of the keys would keep it until it were dismissed by a click or other keystroke.
Re Alex's comment #40 How do you feel about showing enough to be consistent with different operating system's visual style? So on Windows, this may be 7. On OSX, I'd argue that it's enough to show a well-designed and possibly symmetrical view, much like in my mockups. Admittedly my preference would still be to show all content, because I think Ctrl+Tab is a great way to manage it without going to tabs individually, but especially for a first iteration when we have neither a way to scroll nor a way to deal with a billion tabs, perhaps limiting by OS design is a workable solution. Re Alex's comment #41: I agree that the light grey is good at showing non-permanence. The issue is viewing text on different backgrounds. Command+Tab in Apple doesn't need to, because icons are recognizable and the text being highlighted gets a black background. So, if we feel strongly that light grey is important, a solution that allows text to be shown without being too visually distracting (I think big grey black bars behind everything would be). So... any ideas? :)
(In reply to comment #42) > What we could do is not require the user to hold down Control, but rather have > the window by semi-permanent. So it would be summoned with a keystroke such as > ctrl-tab, but a release of the keys would keep it until it were dismissed by a > click or other keystroke. This would also slow down and somewhat alienate Ctrl+Tab, which traditionally takes effect when the keys are released -- in every app that I know, and similar to all Alt+Tab implementations that I know. The point of Ctrl+Tab is that you can hold Ctrl and press Tab n times to get to the n-th item. Otherwise that's is basically what bug 436304 does, except that it uses the tab bar order.
Status: NEW → RESOLVED
Closed: 17 years ago → 17 years ago
Keywords: ue, uiwanted
Resolution: --- → FIXED
Whiteboard: use browser.ctrlTab.recentlyUsedLimit=0
Target Milestone: --- → Firefox 3.1b1
Dao, when I tried with browser.ctrlTab.recentlyUsedLimit set to 0 the list of tabs are presented in reversed order. IMO it is something the user don't expect because ctrl+tab should shift forward through the list of tabs. That means the thumbnails should also be ordered in that way. Shall I file a new bug for this issue?
Did you restart the browser after changing the pref?
(In reply to comment #46) > Did you restart the browser after changing the pref? That's the trick. Thanks. Now the tabs are displayed in the correct order. But in my own interest why a restart is needed here? Changing the pref to 0 switches from MRU to sequential order immediately. So why it cannot be sorted ascending without a restart?
(In reply to comment #47) > in my own interest why a restart is needed here? Because the value is cached. I'm not sure if that's worthwhile, though -- the overhead of always reading the pref directly is probably neglectable.
In that case and even because its a hidden pref we should add some information on SUMO. I think that a lot of users want to switch back to the old behavior. Verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3pre) Gecko/2008090704 GranParadiso/3.0.3pre ID:2008090704 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080921033621 Minefield/3.1b1pre ID:20080921033621
Status: RESOLVED → VERIFIED
Flags: in-litmus?
Keywords: user-doc-needed
The pref for the old behavior is browser.ctrlTab.mostRecentlyUsed.
Dao, as what I can see we have three different modes so far, right? 1. Ctrl-Tab completely disabled 2. Ctrl-Tab enabled but no MRU order 3. Ctrl-Tab enabled and MRU order of a given amount of pages I could imagine that a lot of people would be interested in option 2. That was what I've meant with old behavior in my last comment. I haven't thought about option 1 at that time. Further using browser.ctrlTab.mostRecentlyUsed to switch off Ctrl-Tab is a bit confusing for me because with the pref name I cannot deduce the followed reaction. I know its a bit off-topic here but why that pref name was chosen to enable/disable Ctrl-Tab? E.g. browser.ctrlTab.enabled would be more coherent.
browser.ctrlTab.mostRecentlyUsed doesn't control whether the Ctrl+Tab shortcut is enabled. It controls whether the panel is used, which by default shows previews in the most recently used order. The possibility to disable MRU in the panel is a by-product of bug 450743.
This bug needs to be REOPENED because bug 395980 broke it again. (In reply to comment #51) > 1. Ctrl-Tab completely disabled > 2. Ctrl-Tab enabled but no MRU order > 3. Ctrl-Tab enabled and MRU order of a given amount of pages I'm hoping this bug is about making #2 the default. Here are my comments in bug 395980, which caused this problem: I have stopped using CTRL+TAB since bug 395980 landed because switching tabs with anything more than only two tabs is totally confusing. Users have a mental picture of their tabs based on the order they opened them and, more importantly, the order they visually and physically appear on the tab bar (a constantly visible visual clue!). Therefore, the tab order is more a "physical" order than a time-based order. I strongly suspect that a physical order is much easier to remember than a (invisible) chronological on. Now, clicking CTRL+TAB brings up another visual metaphor in the middle of the screen that competes with and contradicts the visible order of the tabs in the tab bar. The current state caused by this bug is horrible and (for me completely) unusable. Also, if the user wants to toggle between two tabs, he can open them in their own window or move them next to each other (for easy back-and-forth mouse clicking). / Tab 1 \ // Tab 2 \\ / Tab 3 \ +----------------------------------------------+ | | | +------------------------------------+ | | | ___________ | | | | ______ | tab2 | _______ | | | | | tab1 | | | | tab 3 | | | | | | | | | | | | | CTRL+TAB should switch to Tab3. I can't emphasize enough how the two visual tab metaphors (bar & panel) need to be in sync with each other. I'd even like the tabs in the tab bar to become highlighted in sync with the tab panel's shown tab (so the user has correlation, and confirmation for things like: ah yes, i wanted the second-from-last tab). Please make the CTRL+TAB panel list the tabs in the same order they appear on the tab bar.
Peter, set browser.ctrlTab.recentlyUsedLimit to 0 and Firefox's behavior should match your expectation. Please don't spam multiple old bugs with long comments just to ask questions.
Attachment #329880 - Attachment is obsolete: true
(In reply to comment #51) > 1. Ctrl-Tab completely disabled > 2. Ctrl-Tab enabled but no MRU order > 3. Ctrl-Tab enabled and MRU order of a given amount of pages (In reply to comment #52) > browser.ctrlTab.mostRecentlyUsed doesn't control whether the Ctrl+Tab shortcut > is enabled. It controls whether the panel is used, which by default shows > previews in the most recently used order. The possibility to disable MRU in the > panel is a by-product of bug 450743. Ok, so please tell my how I can achieve point 2. I want to use Ctrl-Tab but with the normal tab order. Reading the whiteboard entry tells me to use browser.ctrlTab.recentlyUsedLimit=0 therefor. But setting the pref shouldn't use the panel anymore? Please clearify! Thanks.
browser.ctrlTab.recentlyUsedLimit doesn't affect whether the panel is used.
That's correct. Presumably we were at cross-purposes. Sorry for the confusion. I tested again in detail and everything works as expected. The only thing which we could enhance is the pref name for disabling the panel. browser.ctrlTab.mostRecentlyUsed doesn't really reflect that it is used to enable/disable the panel at all. So to be coherent with all the other services (search in about:config for "enabled") a name like browser.ctrlTab.enabled would be more meaningful. Shall I file a new bug on that?
Why would you assume that browser.ctrlTab.enabled enables/disables the panel rather than the keyboard shortcut?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: