Last Comment Bug 395980 - Implement Ctrl+Tab panel to go to previously selected tabs
: Implement Ctrl+Tab panel to go to previously selected tabs
Status: VERIFIED FIXED
:
Product: Firefox
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
: P1 enhancement with 17 votes (vote)
: Firefox 3.1a1
Assigned To: Dão Gottwald [:dao]
:
Mentors:
http://en.design-noir.de/mozilla/ctrl...
: 438594 451188 470970 (view as bug list)
Depends on: PluginShortcuts 445498 448040 448186 450140 307204 312247 363861 374076 394887 396412 445369 445461 445473 445474 445476 445495 445497 445531 445573 445595 445749 445768 445854 446065 446209 447580 447896 448660 449929 450138 450477 450743 451618 453573 458495 463799
Blocks: 345684 436304
  Show dependency treegraph
 
Reported: 2007-09-12 16:31 PDT by Dão Gottwald [:dao]
Modified: 2014-05-23 14:26 PDT (History)
73 users (show)
reed: wanted‑firefox3+
dao+bmo: in‑testsuite+
mozillamarcia.knous: in‑litmus+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Ctrl+Tab panel v1.0 (33.56 KB, patch)
2007-09-12 16:31 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
v1.1 (extension) (12.33 KB, application/x-xpinstall)
2007-09-18 16:21 PDT, Dão Gottwald [:dao]
no flags Details
patch v1.2 (38.07 KB, patch)
2007-10-11 19:55 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.3 (39.92 KB, patch)
2007-12-12 14:22 PST, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.4 (40.40 KB, patch)
2008-01-05 06:47 PST, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.5 (44.28 KB, patch)
2008-05-14 17:45 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.5.1 (44.28 KB, patch)
2008-05-16 09:01 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.6 (42.56 KB, patch)
2008-05-18 01:26 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.6.1 (42.82 KB, patch)
2008-05-18 11:59 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.6.2 (42.71 KB, patch)
2008-05-22 05:25 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.6.3 (35.15 KB, patch)
2008-06-05 14:11 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.6.4 (34.97 KB, patch)
2008-06-10 10:30 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.7 (38.02 KB, patch)
2008-06-27 17:43 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.7.1 (37.40 KB, patch)
2008-06-28 06:45 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.7.2 (37.01 KB, patch)
2008-06-29 02:28 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.7.3 (37.43 KB, patch)
2008-07-01 05:36 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.7.4 (37.23 KB, patch)
2008-07-01 07:41 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.7.5 (28.77 KB, patch)
2008-07-03 07:29 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review
patch v1.7.6 (34.32 KB, patch)
2008-07-12 14:31 PDT, Dão Gottwald [:dao]
mconnor: review+
Details | Diff | Review

Description Dão Gottwald [:dao] 2007-09-12 16:31:08 PDT
Created attachment 280674 [details] [diff] [review]
Ctrl+Tab panel v1.0
Comment 1 Dão Gottwald [:dao] 2007-09-18 16:21:29 PDT
Created attachment 281387 [details]
v1.1 (extension)

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.
Comment 2 Alex Faaborg [:faaborg] (Firefox UX) 2007-09-18 16:51:14 PDT
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.
Comment 3 Dão Gottwald [:dao] 2007-09-18 16:59:18 PDT
(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.
Comment 4 u88484 2007-09-18 17:00:33 PDT
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.
Comment 5 Dão Gottwald [:dao] 2007-09-18 17:08:47 PDT
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?
Comment 6 u88484 2007-09-18 17:28:24 PDT
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.
Comment 7 Dão Gottwald [:dao] 2007-09-18 17:38:17 PDT
(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).
Comment 8 u88484 2007-09-19 05:09:53 PDT
(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?
Comment 9 Dão Gottwald [:dao] 2007-09-19 06:04:44 PDT
(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.
Comment 10 Alex Faaborg [:faaborg] (Firefox UX) 2007-09-19 17:05:48 PDT
>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.
Comment 11 Dão Gottwald [:dao] 2007-09-19 22:00:34 PDT
(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.
Comment 12 Ria Klaassen (not reading all bugmail) 2007-09-28 00:42:35 PDT
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. 
Comment 13 David J. Lennon 2007-10-09 09:16:34 PDT
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.
Comment 14 Dão Gottwald [:dao] 2007-10-11 19:55:42 PDT
Created attachment 284574 [details] [diff] [review]
patch v1.2

This makes the UI work in RTL mode and fixes performance problems related to latest SVG updates on trunk.
Comment 15 Ivan Ičin 2007-11-07 15:15:48 PST
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.
Comment 16 Dão Gottwald [:dao] 2007-11-07 15:29:50 PST
There are multiple keyboard shortcuts for "Next Tab" and "Previous Tab"; Alt+[Shift+]Tab can be changed without touching the other shortcuts.
Comment 17 bpgarman 2007-11-07 18:11:16 PST
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?
Comment 18 David Monaghan 2007-11-10 23:43:20 PST
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...
Comment 19 RenegadeX 2007-11-19 03:04:02 PST
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.
Comment 20 RenegadeX 2007-11-19 03:12:59 PST
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. :)
Comment 21 Dão Gottwald [:dao] 2007-12-12 14:22:20 PST
Created attachment 292854 [details] [diff] [review]
patch v1.3

updated to trunk
Comment 22 Ivan Ičin 2007-12-12 17:43:13 PST
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. 
Comment 23 Dão Gottwald [:dao] 2008-01-05 06:47:31 PST
Created attachment 295502 [details] [diff] [review]
patch v1.4

updated to trunk
Comment 24 Eugene Savitsky 2008-04-03 05:44:02 PDT
See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=425272
Comment 25 Dão Gottwald [:dao] 2008-05-14 17:45:06 PDT
Created attachment 321008 [details] [diff] [review]
patch v1.5
Comment 26 Dão Gottwald [:dao] 2008-05-16 09:01:04 PDT
Created attachment 321267 [details] [diff] [review]
patch v1.5.1
Comment 27 Dão Gottwald [:dao] 2008-05-18 01:26:27 PDT
Created attachment 321466 [details] [diff] [review]
patch v1.6

- general cleanup, tweaks and fixes
- native popup styling for Linux (black/dark gray doesn't work well without the transparency)
Comment 28 Dão Gottwald [:dao] 2008-05-18 11:59:17 PDT
Created attachment 321504 [details] [diff] [review]
patch v1.6.1

more linux theme love
Comment 29 Mike Connor [:mconnor] 2008-05-21 22:00:54 PDT
Hmm, this doesn't seem to work against Hg trunk.  Dao, can you comment to that?
Comment 30 Dão Gottwald [:dao] 2008-05-22 05:24:59 PDT
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.
Comment 31 Dão Gottwald [:dao] 2008-05-22 05:25:06 PDT
Created attachment 322094 [details] [diff] [review]
patch v1.6.2
Comment 32 Mike Connor [:mconnor] 2008-05-22 07:58:25 PDT
By fail, I mean it seems to apply, and the js code is built, but I don't get any visible changes.
Comment 33 Dão Gottwald [:dao] 2008-05-22 08:32:32 PDT
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.
Comment 34 Mike Connor [:mconnor] 2008-05-22 08:44:17 PDT
the old behaviour.

1.6.2 works just fine though!
Comment 35 Mike Connor [:mconnor] 2008-05-22 08:48:55 PDT
oh, I get it, I probably only had two tabs open.  fail == me.
Comment 36 Dão Gottwald [:dao] 2008-06-05 14:11:36 PDT
Created attachment 323925 [details] [diff] [review]
patch v1.6.3

makes use of bug 430906
Comment 37 Dão Gottwald [:dao] 2008-06-10 10:30:23 PDT
Created attachment 324473 [details] [diff] [review]
patch v1.6.4

fixed the panel's position where the task bar is attached to the top or left side of the screen.
Comment 38 Jesse Ruderman 2008-06-14 01:15:46 PDT
*** Bug 438594 has been marked as a duplicate of this bug. ***
Comment 39 Valentin Laube 2008-06-15 09:48:57 PDT
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.
Comment 40 John Mellor (Jomel) 2008-06-15 10:23:53 PDT
(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.
Comment 41 Ivan Ičin 2008-06-15 11:31:06 PDT
(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.
> 

Comment 42 Dão Gottwald [:dao] 2008-06-27 17:43:49 PDT
Created attachment 327206 [details] [diff] [review]
patch v1.7

complete overhaul
Comment 43 Dão Gottwald [:dao] 2008-06-28 06:45:08 PDT
Created attachment 327249 [details] [diff] [review]
patch v1.7.1

I couldn't test it yet, but this might improve multi-monitor support.
Comment 44 Dão Gottwald [:dao] 2008-06-29 02:28:09 PDT
Created attachment 327306 [details] [diff] [review]
patch v1.7.2

Now using a "KUI-panel" class for reuse in bug 434946 and elsewhere.
Comment 45 Dão Gottwald [:dao] 2008-07-01 05:36:14 PDT
Created attachment 327589 [details] [diff] [review]
patch v1.7.3

fixed an issue with Google Docs (content shouldn't receive key events while the panel is open)
Comment 46 Robert Longson 2008-07-01 06:22:29 PDT
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.


Comment 47 Dão Gottwald [:dao] 2008-07-01 07:41:53 PDT
Created attachment 327607 [details] [diff] [review]
patch v1.7.4

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

thanks, Robert!
Comment 48 Dão Gottwald [:dao] 2008-07-03 07:29:57 PDT
Created attachment 327964 [details] [diff] [review]
patch v1.7.5

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.
Comment 49 Dão Gottwald [:dao] 2008-07-12 14:31:39 PDT
Created attachment 329257 [details] [diff] [review]
patch v1.7.6

Moved some basic rules to browser/base/content/browser.css for a working out-of-the-box UI with unmodified third-party themes.
Comment 50 Mike Connor [:mconnor] 2008-07-15 08:45:13 PDT
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!
Comment 52 Jim Jeffery not reading bug-mail 1/2/11 2008-07-15 12:02:12 PDT
How do you turn it off ?  
Setting the pref to 0 (zero) or 100 does not change the action, it still shows the preview. 

Comment 53 Dão Gottwald [:dao] 2008-07-15 12:33:43 PDT
(In reply to comment #52)
> How do you turn it off ?

There's no way currently, but feel free to file a bug.
Comment 54 AKIHIRO Misaki (a.k.a Kuden) 2008-07-16 06:38:51 PDT
Dão, Windows and OS X supports xul:panel transparent.
However, is Linux supported?
Comment 55 Dão Gottwald [:dao] 2008-07-16 06:48:28 PDT
(In reply to comment #54)
> Dão, Windows and OS X supports xul:panel transparent.
> However, is Linux supported?

No, see bug 408284.
Comment 56 Hideo Oshima 2008-07-16 06:52:07 PDT
(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.
Comment 57 sibbl 2008-07-17 03:26:38 PDT
please add a feature to disable it ... i don't want to use this or page up/down-keys :o
Comment 58 u88484 2008-07-17 04:45:46 PDT
(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
Comment 59 José Jeria 2008-07-18 04:13:03 PDT
(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.
Comment 60 Jose Fandos 2008-07-18 14:39:07 PDT
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.
Comment 61 Per Ångström 2008-07-19 03:04:19 PDT
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).
Comment 62 Dão Gottwald [:dao] 2008-07-19 09:06:27 PDT
(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.
Comment 63 Henrik Skupin (:whimboo) 2008-07-20 15:00:13 PDT
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
Comment 64 Henrik Skupin (:whimboo) 2008-07-20 16:14:00 PDT
Dao, are there planned any automated tests for all of these bugs?
Comment 65 Shawn Wilsher :sdwilsh 2008-07-20 21:27:17 PDT
(In reply to comment #64)
> Dao, are there planned any automated tests for all of these bugs?
There should be, IMO.
Comment 66 Dão Gottwald [:dao] 2008-07-21 01:01:03 PDT
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).
Comment 67 Henrik Skupin (:whimboo) 2008-07-21 11:46:54 PDT
Dao, will the work be done in a separate bug?
Comment 68 Dão Gottwald [:dao] 2008-07-21 14:51:50 PDT
No, we have the in-testsuite flag for that.
Comment 69 Shawn Wilsher :sdwilsh 2008-07-22 21:47:18 PDT
There should be some tests for the basic functionality of this feature too...
Comment 70 Hans Schmucker 2008-07-27 09:23:36 PDT
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.
Comment 71 Hans Schmucker 2008-07-27 09:35:47 PDT
Oops, wrong bug id: Bug #448186 is what I meant
Comment 72 Eugene Savitsky 2008-07-29 17:40:32 PDT
https://bugzilla.mozilla.org/show_bug.cgi?id=425272

It seems related?
Comment 74 Marcia Knous [:marcia - use ni] 2008-08-14 09:41:16 PDT
https://litmus.mozilla.org/show_test.cgi?id=5893 added to Litmus.
Comment 75 Dão Gottwald [:dao] 2008-08-19 07:27:12 PDT
*** Bug 451188 has been marked as a duplicate of this bug. ***
Comment 76 hasan 2008-09-19 09:39:13 PDT
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.
Comment 77 Alex Faaborg [:faaborg] (Firefox UX) 2008-09-19 12:04:49 PDT
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.
Comment 78 hasan 2008-09-19 22:58:31 PDT
(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?
Comment 79 -fullmetaljacket- 2008-09-19 23:12:19 PDT
> (In reply to comment #77)
shiretoko (firefox 3.1)
Comment 80 Jesse Ruderman 2008-09-20 14:44:25 PDT
*** Bug 456217 has been marked as a duplicate of this bug. ***
Comment 81 Peter Lairo 2008-09-29 04:18:14 PDT
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.
Comment 82 Peter Lairo 2008-09-29 04:37:35 PDT
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) ;-)
Comment 83 Worcester12345 2008-12-01 10:34:09 PST
(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.
Comment 84 Dão Gottwald [:dao] 2008-12-24 13:22:19 PST
*** Bug 470970 has been marked as a duplicate of this bug. ***
Comment 85 Charles Harrison 2008-12-24 14:25:10 PST
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;

Note You need to log in before you can comment on or make changes to this bug.