User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1b1pre) Gecko/20081003 Minefield/3.1b1pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1b1pre) Gecko/20081003 Minefield/3.1b1pre As a user, I need something to know witch tab in the tab bar I select in the ctrl tab preview. The old ctrl-tab allow me to visualy localise "where I am in my open tabs". It allow me to organize my browse, as I organize my files/folders depending what I want to do with. (I remember reading something about tabs' uses in planet mozilla, but don't found this study now) When a user open a tab, Fx give it a place, and the user use it to identify the tab. To organize it browse, the user can modify the tab's order. But with ne new behavirour, he hasn't a way to see where he is seeking in his browsing-map. With the new behaviour, you can no longer associate a tab-bar location with the tab preview, so it's had to mentaly represent where you are in your tab mental map. It hurt the spatial memory. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: Can't associate the new ctrl-tab map presented in the preview with my mental map and the spatial tab bar map. Expected Results: Design a UI that consider the link between ctrl-map and the user spatial mental memory

This bug is extremely important, for the reasons given in bug 395980 Comment #81 https://bugzilla.mozilla.org/show_bug.cgi?id=395980#c81 PS. Out of curiosity: Why is *wanted* Firefox 3.1 not selectable?

I disagree that this bug is a dup of bug 445499. I use a nighly with this bug resolved and I've always the issue described. Actually, the UI don't give a peace of information to locate to witch tab the user will jump. Witch tab will have the focus when I release ctrl-tab keys ? User need something that say "this thumbnail correspond to this tab (I'm speaking about the component in the tab bar), so when I'll release ctrl-tab keys I will be in that place in the tab bar". With the actual behaviour, this is not predictable. I think that the actual design or behaviour don't represent how users use tabs. On mac, this is different when you use Exposé, even if you organize your windows spatially, and that exposé change they positions, the animation show you "hey, this windows that were there, I temporally move it there to help you make a decision on what you want to do, and after, I'll show you that I will restore your windows initial positions, and dynamically show you the way I use to go from the initial situation to the one you order me". The is no brakes between the initial, the triage and the final situations. As a comparison, when you overfly a tab with the mouse, it give you the information "if you do an action with me, I'll have the focus" by changing it colour/transparency. In that case, the result of the click action is predictable. For Fx ctrl-tab, you (the user) need to predict what will be the final situation on the browser's controls you will have at this time (and not only during the the transitional situation, witch expose you the result with other controls/UI elements, that don't give advice about the result on the "normal" browsing environment). That is a question of link between an ad-hoc (external) panel to control an in-hoc (internal) element. The thumbnail represent the content, not the object you want to do an action with (the tab element in the tab bar). So I think, the actual design lack something to link the metaphor of the tab (the thumbnail) and the control/component tab (the tab in the tab bar). This is a bit different from the bug 445499, even if it resolution is maybe a part of the resolution of this bug (not sure). So, please, reopen this bug.

Even if bug 458495 is fixed, I don't think this is. Let me know what you think for something like that. (I made it in 1 min, so it's a draft ;-)