Some minor changes. This extension also contains the All-Tabs panel, but I'm only interested in the ui-review for Ctrl-Tab right now.

We should consider how we want to style this window on each platform. For OS X I was thinking it would make sense to simply match the appearance of the command-tab window (large rounded corners, lighter grey background). And on Vista, I think matching the start menu with the same outline and gradient would make sense (like http://people.mozilla.com/~faaborg/files/20070705-kui/i1kuiTagging.png_large.png). Not sure what we should do for XP. I'll try to get exact RGB values, levels of transparency, and size of the curved corners for each platform. I also need to check out leopard to make sure they didn't change anything.

(In reply to comment #2) > Not sure what we should do for XP. I'd say the same as for Vista. > I'll try to get exact RGB values, levels of transparency, and size of the > curved corners for each platform. I also need to check out leopard to make > sure they didn't change anything. That would be very helpful, thanks.

Dao, I'm not sure if you are also looking for feedback but here are some issues I have found: 1) Ctrl+tab does nothing at all except in the all-tabs panel These have to do with the all-tabs panel 1) about:blank tabs do not show up in the panel 2) have a tab with content open, tab with about:blank, tab with content open and there is a huge gab in between the two with content...where the about:blank tab should be 3) with problem #2 setup moving mouse between the filter and where the about:blank tab should be causes the background to heighten. 4) hovering over a non-focused tab's preview causes the preview to expand (probably intended) 5) The brown background for the tab's title should be prettier which I'm sure you agree. 6) hitting ctrl+tab in the all-tabs panel to where the about:blank tab should be puts a blank brown box around what should be the about:blank's preview 7) hitting ctrl+tab in the all-tabs panel (with problem #2 setup) to a tab with a preview puts a focus ring around the first tab (as long as the first tab had focus first before opening the all-tabs panel) 8) same setup as problem #2, giving the filter focus removes the gap reported in problem #2 Open tab with content, about:blank tab, tab with content, about:blank tab and the fourth tab has an untitled white preview for the about:blank tab which should be what problem #2's should be like.

Kurt, I don't see what you're seeing. Blank tabs work for me like all others, and Ctrl-Tab works for me like it works without the All-Tabs panel (e.g. patch 1.0 from above). Do you have extensions installed that could cause problems? Which OS do you use?

It was your extensinon smoothscroll 1.0 that you attached to some other bug...sorry about that! Ok well now that everything is working properly my only suggestions are about the brown background and the ctrl+tabbing preview (very nice by the way) should have a max of an odd numbered tabs like 5 instead of the current even numbered 6, so that way the focused tab is in the center of all the other tabs shown there.

(In reply to comment #6) > It was your extensinon smoothscroll 1.0 that you attached to some other > bug...sorry about that! Yeah, somehow I managed to smuggle an old version of Ctrl-Tab in to bug 380960. > Ok well now that everything is working properly my > only suggestions are about the brown background and the ctrl+tabbing preview > (very nice by the way) should have a max of an odd numbered tabs like 5 instead > of the current even numbered 6, so that way the focused tab is in the center of > all the other tabs shown there. It's asymmetric by design, as you're more likely to scroll forwards (Ctrl+Tab) rather than backwards (Shift+Ctrl+Tab).

(In reply to comment #7) > It's asymmetric by design, as you're more likely to scroll forwards (Ctrl+Tab) > rather than backwards (Shift+Ctrl+Tab). > True but its just aesthetically pleasing in the middle, plus it would be a code savings. Since for the RTL readers you would (if keeping with your thought) have to flip this around. I do not know how hard that would be but I do know it would save on code size to be in the middle. Even if its a little win, its still a win. What does the vista alt+tab, IE7 tab switcher, opera's? look like?

(In reply to comment #8) > (In reply to comment #7) > > It's asymmetric by design, as you're more likely to scroll forwards (Ctrl+Tab) > > rather than backwards (Shift+Ctrl+Tab). > > > > True but its just aesthetically pleasing in the middle That argument isn't qualified to rule out the usefulness that comes with focusing on forward scrolling ... > plus it would be a code > savings. Since for the RTL readers you would (if keeping with your thought) > have to flip this around. I do not know how hard that would be but I do know it > would save on code size to be in the middle. RTL will have to be tested and fixed, if necessary. If that means to add 5, 10 or 30 code lines, then I'm willing to pay that price. > What does the vista alt+tab, IE7 tab switcher, opera's? look like? I don't know about Vista, but neither IE7 nor Opera have something similar.

>RTL will have to be tested and fixed, if necessary. If that means to add 5, 10 >or 30 code lines, then I'm willing to pay that price. I totally agree, the best user experience should determine the implementation, not the other way around. In terms of the user experience: Personally I would like to see the selection move from left to right, and have the row of tabs scroll only when the selection gets to one space from the far right. Since the tabs are in order of most recently used, and most people use this interface to switch between the last few accessed tabs, people probably won't hit the end of the visible row that often. If they do, maybe we should increase from 6 to a lager number, but we will need to ship this in a beta before we can get that kind of feedback.

(In reply to comment #10) > In terms of the user experience: > Personally I would like to see the selection move from left to right, and have > the row of tabs scroll only when the selection gets to one space from the far > right. Since the tabs are in order of most recently used, and most people use > this interface to switch between the last few accessed tabs, people probably > won't hit the end of the visible row that often. If they do, maybe we should > increase from 6 to a lager number John Marshall's KUI prototype does that and I found it rather confusing. While his panel could be polished a bit, I currently don't see a way to fundamentally improve that experience.

I tried the extension from comment 0 but I get the wrong picture of the active tab (the previous site). It has the right name however. Only after clicking on another tab it loads the right picture.

Fantastic added functionality - I agree though that when Ctrl+tabbing that the current window should be presented in the center, with the window title also being centered, instead of left justification... Would also be good to be able to scroll through windows using the keyboard arrow keys, instead of constant ctrl-tabbing. When initally control tabbing though to bring up the dialog i dont think it should automatically change tabs - If im just looking at what windows i have open when i release ctrl+tab i'm displayed another tab to the one i was originally browsing.. on the tab browser would it be possible to have alpha fade in and out on the selected tab rather than a zoom? would look cleaner.

This makes the UI work in RTL mode and fixes performance problems related to latest SVG updates on trunk.

First of all, 65% percent of population are visual thinkers, but I don't belong to that group. Obviously, ctrl+tab visualization is useless to me, but that's not the argument not to use it. My argument is that current implementation is unnecessary turning ctrl+tab (my mostly used shortcut) into something useless to me, and I don't think it is useful to anybody. First of all, I don't quite understand the value of preview in ctrl-tab. Alt-tab in Windows was invented at the time hardware was not capable of quickly rendering windows, so pressing alt-tab several times to switch to 5th window would be painfully slow. Second reason is that alt+tab switching order is not the same like order in taskbar, so sometimes you are not sure whether you should be pressing alt+tab or alt+shift+tab. Other than that, I can't see any reason for its existance. So, if my hardware is capable of immediate rendering of the page, having preview instead of the real thing is something that is out of mind. Having preview of several next pages makes some sense. Though I think it is just perception - again it is quicker to press ctrl+tab necessary numbers of times than to waste time looking at preview and then again pressing ctrl+tab same number of times. But even in this case, the highest value is if you have several pages from the same site. Unfortunately, their preview turns to be the same, and preview in current implementation even hides titles, which probably have much higher value than visualization in this case. So if this is to be implemented please keep in mind this: 1. don't turn off real page switching with ctrl+tab 2. keep this at the bottom of page If those 2 reasons are fulfilled, I don't think that I would mind anything, though I still think it is more eye-candy than some real functionality. As said above, it might just slow down productivity and not increase it. Just to note I didn't comment the all-tabs, but I think it is good functionality.

There are multiple keyboard shortcuts for "Next Tab" and "Previous Tab"; Alt+[Shift+]Tab can be changed without touching the other shortcuts.

Just some comments from trying v1.1 with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007110705 Minefield/3.0a9pre ID:2007110705 1) The thumbnails look to be poor quality. Whether this is due to the resizing algorithm or the type of compression used I have no idea. 2) I feel the 'list all tabs' functionality should be the default action assigned to ctrl-tab, simply for the search functionality. The action of pressing ctrl-tab, typing what you're looking for, pressing enter to select it is far more efficient than going through each tab. It's similar to how Vista's new start menu works. 3) When using the browser in a window the ctrl-tab panel is not confined to the window but overlaps on the sides. Intended behaviour?

I agree with Ivan even though I do operate both visually and programmatically, so I would use this sometimes therefore would prefer something like ctrl+alt+tab (and an option for those who want to get rid of the old ctrl+tabbing on your super fast computers too.) On another note, can we add scrolling to this? That brings me to mentioning that right now if you ctrl+tab (hold ctrl) and scroll the font size is increased/decreased... just noticed is all, not sure if that's bad...

Hey my 2-cents+, having tried out the extension. - 1) In its currently form, I'd had to vote that it should remain an extension. (Beltzner said as much over a year ago at https://bugzilla.mozilla.org/show_bug.cgi?id=345684#c5 ). It's admittedly pretty slick (visually better than I expected, even), but I *don't* believe that being able to flip through thumbnails of your most-recently opened tabs is a "must have" feature, and additionally, on slower computers (such as the P3 and P4 I tested it on), it can, at times & depending on content, be slow to create/draw the thumbnails. So slow the wait can be annoying. Other times, and on faster computers - there's delay is hardly noticeable--good. - 2) Though I would still probably argue that it should be left as an extension even if it included the following suggestion, I would be *more agreeable* to this being included as a standard feature IF, and only if, it included an option to present the Ctrl+Tab thumbnails in the 'standard' tab order - rather than the 'most recently used' tab order, as the extension currently does. However, when I asked Dão about this on IRC the other day, he said he had no plans for it. While I understand that the idea (as suggested by Beltzner on MDAF in June) is to emulate the Alt+Tab feature of OS's where the app icons are presented in most-recently used order, please don't go forcing something on me or any other users that is a confusing change - the behaviour differs greatly from what most users have become accustomed to in Firefox. (Up until now, Alt+Tab has been "jump to the next tab as it appears on the Tab Bar" and Alt+Shift+Tab has been "jump to the previous..") Implementing that would of course mean that the request in Comment 13 (to position the current focused preview in the middle of the thumbnails shown) would now make sense as what's "before" would be equally as relevant as what is "after". But that might complicate & confuse things..... 3) One last thing - the 'All Tabs' button is very nice, in fact I'd say it's actually more useful than the Ctrl+Tab function especially because of the cool filter function. My only suggestion: the filter could be greatly improved with a "quick clear" button to reset it.

Sorry for the bugspam(I wish Bugzilla had a "preview before submit" function!) but I just noticed an obvious goof in my last msg- it should have read "Up until now, CTRL+Tab has been...." and "CTRL+Shift+Tab has been". I'm sure if I didn't correct myself, someone else would have. :)

updated to trunk

In comment #15 I argued about why this is not a good UI, but I forgot to comment on why recent tab order switching is not a good practice for tabs. I hope that we agree that ideally ctrl+tab should switch to tab user wants to see at that moment. As usage patterns may vary, whichever algorithm is implemented will not work well in 100% of cases. So the question is which method guesses better what user want. In Windows (and programs like Visual studio) there is a good argument for recent program/document switching - copy and paste wouldn't work normally otherwise, and it would be hard to compare documents. As this is very frequent user scenario, this really makes sense. In browsers, work-flow is different. Copy and paste is not used almost at all, and comparing documents might be interesting to some extent (but in most cases tabs to compare a nearby, so switching order doesn't make great difference). But most frequent scenario is Google search or Bloglines read or Google news: you have one page with collection of links, you open tabs from it and subsequently read tabs, and then usually come back to the first page to find some more links (or to close it if job is well done). With recent tab switching order it is so unpleasant to do that everyone would give up using keyboard. Personally I wouldn't use Firefox if this is to be implemented this way (generally speaking, there will probably be some extension to override this). Not because I like to be smart or anything, but because this is No. 1 reason I don't even think to use Opera.

updated to trunk

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=425272

- general cleanup, tweaks and fixes - native popup styling for Linux (black/dark gray doesn't work well without the transparency)

more linux theme love

Hmm, this doesn't seem to work against Hg trunk. Dao, can you comment to that?

To what extent does it fail? The tryserver accepts it. I've created an Hg diff previously, which was basically the same except that it couldn't be applied automatically.

By fail, I mean it seems to apply, and the js code is built, but I don't get any visible changes.

What happened when you pressed ctrl/cmd+tab? The old "advance selected tab" behavior or nothing at all? Note that the all-tabs panel isn't included yet, I wanted to do that in a separate bug.

the old behaviour. 1.6.2 works just fine though!

oh, I get it, I probably only had two tabs open. fail == me.

makes use of bug 430906

fixed the panel's position where the task bar is attached to the top or left side of the screen.

i tried the extension some time ago and i'm sorry if the behavior changed and my comment doesn't apply anymore... the problem i see here is that the most recently used (mru) cycling of tabs introduces a new (and hidden unless you press ctrl+tab) ordering of the tabs in addition to the visible one in the tabbar. i tend to plan my keypresses before i do them and the behavior of this extension, visual studio and other editors was really annoying. i planned my actions and while executing them noticed that the developer decided that i'm wrong and had to replan my actions. this could have worked if i had the image of the hidden tab order in my mind, but this is pretty hard if it conflicts with the order i see on the screen or i leave the computer for some time. the solution to this problem is to either sort the displayed tabs in the tabbar by mru order or simply use the displayed order to cycle the tabs (like it's done now). i prefer the second variant because i'm not convinced that the mru order would help anyone, maybe data from the spectator addon could be use to clarify here.

(In reply to comment #39) > the solution to this problem is to either sort the displayed tabs in the tabbar > by mru order or simply use the displayed order to cycle the tabs (like it's > done now). Ctrl-Page Up/Page Down will continue to cycle through the tabs in tab bar order. And while MRU order isn't contantly visible (though you will be able to preview it with the Ctrl-Tab popup), people generally remember at least the most recent few tabs they've accessed, and these are also the tabs they're most likely to want to get back to. Better ordering tabs in the tab bar is still important though - see Bug 262459.

(In reply to comment #40) > Ctrl-Page Up/Page Down will continue to cycle through the tabs in tab bar > order. But you can do ctrl+tab with one hand and have mouse on other hand, with pageup it is impossible. > And while MRU order isn't contantly visible (though you will be able to preview > it with the Ctrl-Tab popup), people generally remember at least the most recent > few tabs they've accessed, and these are also the tabs they're most likely to > want to get back to. Except in cases like reading sites/news and searching the web which take only 90% of activity... See comment #20 > > Better ordering tabs in the tab bar is still important though - see Bug 262459. >

complete overhaul

I couldn't test it yet, but this might improve multi-monitor support.

Now using a "KUI-panel" class for reuse in bug 434946 and elsewhere.

fixed an issue with Google Docs (content shouldn't receive key events while the panel is open)

You are using SVG opacity. Do you really need to? Could you get away with using fill-opacity and/or stroke-opacity instead? Your svg explicitly sets some attributes to their default values. These could be omitted e.g. mode="normal" on feBlend.

removed opacity on SVG elements; removed some attributes that don't seem to make a difference. thanks, Robert!

The scale3x algorithm works well for certain kinds of favicons but produces ugly results for others. I decided to drop it, which simplifies things a lot.

Moved some basic rules to browser/base/content/browser.css for a working out-of-the-box UI with unmodified third-party themes.

Comment on attachment 329257 [details] [diff] [review] patch v1.7.6 r=mconnor I'm not sure at all that this is the final visual presentation, but I like the interaction a lot and the code looks like its solid, so let's get it landed!

How do you turn it off ? Setting the pref to 0 (zero) or 100 does not change the action, it still shows the preview.

(In reply to comment #52) > How do you turn it off ? There's no way currently, but feel free to file a bug.

Dão, Windows and OS X supports xul:panel transparent. However, is Linux supported?

(In reply to comment #54) > Dão, Windows and OS X supports xul:panel transparent. > However, is Linux supported? No, see bug 408284.

(In reply to comment #55) > (In reply to comment #54) > > Dão, Windows and OS X supports xul:panel transparent. > > However, is Linux supported? > > No, see bug 408284. I filed bug 445498. If it is redundant please mark as dup.

please add a feature to disable it ... i don't want to use this or page up/down-keys :o

(In reply to comment #57) > please add a feature to disable it ... i don't want to use this or page > up/down-keys :o Read the dependencies to this bug https://bugzilla.mozilla.org/showdependencytree.cgi?id=395980&hide_resolved=1

(In reply to comment #53) > (In reply to comment #52) > > How do you turn it off ? > > There's no way currently, but feel free to file a bug. > Bug 445981 was filed.

The best thing since LastTab was invented! Just how tabbing was meant to be used with the keyboard ;) Sorry for the excited comment. Just found out about this. Now to specifics. LastTab, the plugin, when closing one tab it takes you to the previously visited tab. This patch doesn't. I haven't been using it long enough (just a few minutes, really) to decide if this makes more sense, but wondered if any thought had been given. Right now I'm feel a bit lost when taken to the next tab to the right rather than the one prev. visited. Also, the visited tabs order is not saved between sessions. Used to that, thanks to LastTab. Wondered if that's possible to be considered at all.

I have a suggestion for improvement: Let the splash be sensitive to mouse clicks, so that clicking on any of the displayed thumbnails will take you directly to that tab, no matter which thumbnail is currently the active one. And I wouldn't mind seeing five or more thumbnails, instead of just three (unless performance is severely affected).

(In reply to comment #60) > Now to specifics. LastTab, the plugin, when closing one tab it takes you to the > previously visited tab. This patch doesn't. I haven't been using it long enough > (just a few minutes, really) to decide if this makes more sense, but wondered > if any thought had been given. Right now I'm feel a bit lost when taken to the > next tab to the right rather than the one prev. visited. The tab to the right is exactly what you want when going through a bunch of tabs opened in the the background. That said, often enough the current algorithm also takes you to tabs that don't fit into your work flow at all. Maybe it just needs tweaking, or maybe the right way is a combination of both approaches. > Also, the visited tabs order is not saved between sessions. Used to that, > thanks to LastTab. Wondered if that's possible to be considered at all. That's bug 445461. (In reply to comment #61) > I have a suggestion for improvement: Let the splash be sensitive to mouse > clicks, so that clicking on any of the displayed thumbnails will take you > directly to that tab, no matter which thumbnail is currently the active one. That's bug 445497.

Due to remaining issues are handled by other bugs I can verify this enhancement with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008071806 Minefield/3.1a1pre ID:2008071806 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008072003 Minefield/3.1a1pre ID:2008072003

Dao, are there planned any automated tests for all of these bugs?

(In reply to comment #64) > Dao, are there planned any automated tests for all of these bugs? There should be, IMO.

Automated tests aren't planned for _all_ of these bugs. There are "bugs" that don't make sense to be tested (bug 445473), bugs that are really core issues (bug 445474), bugs that should be tested (bug 445768) and bugs that might be hard to test (bug 445573).

Dao, will the work be done in a separate bug?

No, we have the in-testsuite flag for that.

There should be some tests for the basic functionality of this feature too...

Added block by Bug #395980 "Canvas drawWindow with context.scale does not scale bitmap fonts", because it makes for a very strange experience if a lot of pages you're visiting use Courier.

Oops, wrong bug id: Bug #448186 is what I meant

https://bugzilla.mozilla.org/show_bug.cgi?id=425272 It seems related?

https://litmus.mozilla.org/show_test.cgi?id=5893 added to Litmus.

The way that is used by Microsoft to select tabs in stack order is very good and user-friendly. But Mozilla insists on not adding this feature to Firefox unreasonably Because IE is a competitor of Firefox.

Commenting after a bug has been resolved with a personal opinion is a violation of bugzilla etiquette. Normally I wouldn't call that out, but mostly I want to emphasize that we have absolutely no qualms with leveraging good UI ideas created by others, which certainly includes Microsoft. The assumption that we are refusing to copy a particular behavior out of pride is inaccurate, we are refusing to copy it because a quick keystroke to go back to the most recently used tab is simply more useful. It's like a back button for tab switching.

(In reply to comment #77) > Commenting after a bug has been resolved with a personal opinion is a violation > of bugzilla etiquette. Normally I wouldn't call that out, but mostly I want to > emphasize that we have absolutely no qualms with leveraging good UI ideas > created by others, which certainly includes Microsoft. The assumption that we > are refusing to copy a particular behavior out of pride is inaccurate, we are > refusing to copy it because a quick keystroke to go back to the most recently > used tab is simply more useful. It's like a back button for tab switching. Is this problem resolved in Firefox? I have Firefox 3.0.1. Which version of Firefox has this feature?

> (In reply to comment #77) shiretoko (firefox 3.1)

Is there a bug to undo this bug? Or a bug that adds an option to disable it? Or a bug that adds a switch *and* makes this the non-default? I have stopped using CTRL+TAB since this bug 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 switches 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. Please mark this bug INVALID.

Bug 445499 needs to be REOPENED to fix what this bug broke. https://bugzilla.mozilla.org/show_bug.cgi?id=445499 (there is some humor in these two bugs ping-pong fixing/breaking each other, but I hope a more constructive solution can be found) ;-)

(In reply to comment #82) > Bug 445499 needs to be REOPENED to fix what this bug broke. > > https://bugzilla.mozilla.org/show_bug.cgi?id=445499 > > (there is some humor in these two bugs ping-pong fixing/breaking each other, > but I hope a more constructive solution can be found) ;-) There is an extension called "Tab Clicking Options" at http://twanno.mozdev.org/ Perhaps this can be modified or copied and have the new CTRL-TAB functions added there.

I came here because a bug that I filed was marked as a duplicate of this (though I would dispute if that is actually true): Bug 470970 - Control-Tab and Control-Shift-Tab don't cycle through the Tab History List https://bugzilla.mozilla.org/show_bug.cgi?id=470970 I write the same comments there that I wrote in bug 465076. As a long-term user that has grown up with (in a computing sense) with Control-Tab and Control-Shift-Tab in an MDI cycling through the document history list, aka MRU list or sometimes Z-order, I'm really shuddering at what I'm reading here. Please see my bug for a description of how Control-Tab and Control-Shift-Tab are *supposed* to work, at least in all Windows environments since 3.1. This behaviour is already broken in FF, but instead of just fixing it, you seem hell bent on changing it permanently to something different so that it can never work as it always has in Windows environments. Control-Tab, along with its window counterpart, Alt-Tab, are the most useful shortcuts in a Windows environment. If you must do this: 1) Fix Control-Tab and Control-Shift-Tab to behave as they *should*; 2) Use a shortcut other than Control-Tab or Control-Shift-Tab for extra tab choosing functionality; 3) Do NOT include it in the standard build, make it a downloadable add-on for those that actually want it;