Open Bug 586155 Opened 14 years ago Updated 2 years ago

Only display Aero Peek tab previews on a delayed hover

Categories

(Core :: Widget: Win32, defect, P3)

x86
Windows 7
defect

Tracking

()

Future
Tracking Status
blocking2.0 --- -

People

(Reporter: faaborg, Unassigned)

References

Details

(Keywords: ux-efficiency)

Our current support for Aero Peek on Windows 7 is platform native, but is nonetheless making a lot of interactions with Firefox slow and clunky.  We are treating tabs as windows (as IE8 does as well), and asking the user to select a particular tab in order to switch to Firefox.

When the user just wants to bring Firefox to the front (perhaps to get a full view of the active tab), they need to identify the active tab in the set of aero peek thumbnails.

Also, if the user wants to create a new tab, they need to select which of thier existing tabs they would like to focus prior to creting the new tab.  This is cognitively difficult because the correct answer is none of them (not in the sense of it being impossible to figure out, but just a momentary mental glitch as you are completing a sequence of tasks).

Proposed behavior:

-When the user clicks the Firefox button we display the Firefox window immediately, maintaining the active tab (similar for instance to Chrome).

-On a delayed hover, we display the tab previews in Aero Peek (this is already the standard behavior).

An example of this mixed behavior is Windows Media Player, which focuses on click immediately, and on hover displays extra controls for the user to interact with.
Requesting blocking since this effects a very large number of daily interactions with the browser for a large section of our user base.  Also it effects how lightweight and snappy the browser feels (visual complexity, time to focus, etc.)
blocking2.0: --- → ?
I think this is the right behaviour, and we should either get this or consider turning Aero Peek off by default. Felipe/Rob, any idea if there are Windows APIs we can use to make this happen?
blocking2.0: ? → final+
We have very little control over the peek UI.
I'm not sure there are any Windows APIs to help us here. We know how to get the tabs to appear on hover (at least, I have a plan, Felipe might have a proof-of-concept). The problem though is that we don't have a great idea of when to stop displaying the tabs. There are some possible hacks we can try.

I also should note that if you just want the last used Firefox window back, Ctrl+Click on its taskbar icon. When we have tab previews up, this conveniently selects the last tab you used (the one you probably want to go back to). Keep ctrl+clicking to cycle through your windows/tabs (the previews really) in MRU order. We have no way to change this behavior.
No longer blocking; users have the option to turn Aero Peek off, and we might just make that the default behaviour based on feedback.
blocking2.0: final+ → -
>users have the option to turn Aero Peek off, and we might
>just make that the default behaviour based on feedback.

I recommend we turn it off until we can turn it on correctly.  I know a lot of users currently really like the feature, but it significantly slows down access to Firefox (having to go to secondary UI just to activate the window).
(In reply to comment #6)
> I recommend we turn it off until we can turn it on correctly.  I know a lot of
> users currently really like the feature, but it significantly slows down access
> to Firefox (having to go to secondary UI just to activate the window).
I'm kinda confused why 1) this discussion is happening in a bug and not the newsgroups, and 2) why we want to be different from other native windows apps for windows 7.  Yes, it's different, but most apps on windows do this in my experience.
(In reply to comment #0)
> Proposed behavior:
> 
> -When the user clicks the Firefox button we display the Firefox window
> immediately, maintaining the active tab (similar for instance to Chrome).

Chrome doesn't support tab previews in their current release. IMHO the fact that we do is a plus for us, not a minus.
IE9 has the same click behavior as we do, so I see this more as a shortcoming in the windows taskbar than anything else. Which isn't to say we shouldn't try to work around it, but.. as rob points out, ctrl-click is the way to bring up the last tab. That's the way the windows taskbar currently works.
>No longer blocking; users have the option to turn Aero Peek off, and we might
>just make that the default behaviour based on feedback.

I've filed bug 605338 to turn Aero peak off until we can get this bug addressed.  This isn't ideal, but is I think the best option given available time.
Blocks: 587440
Blocks: 581726
Blocks: 591434
(In reply to comment #8)

> Chrome doesn't support tab previews in their current release. IMHO the fact
> that we do is a plus for us, not a minus.

Well, I think this is not really true. I’ve been using some nightlies of Chrome a while ago and I remember that they were experimenting with Aero Peek as it is implemented in Firefox 4 now. They’ve probably realised the problems and as Chrome is really devoted to speed they turned it off for default. So it is not that Chrome doesn’t support it, it just isn’t used.
Component: Shell Integration → Widget: Win32
Product: Firefox → Core
QA Contact: shell.integration → win32
Target Milestone: --- → Future
Depends on: 616720
No longer blocks: 581726
I did some poking around on this. I didn't find anything in the apis to support control over display of thumbnails. There's always a way to do things on windows, but independent of hacking explorer.exe's ui (through for example, subclassing maybe) I'm not seeing any options here.
FWIW, we Chrome folks have similar reactions to the system-native Peek UI and similar desires around what UI we'd like to implement.  If you can pull this stuff off feel free to ping me as I'm interested in how it's done :)
I know this is still being worked on, but Minefield flashes before the screen redraw when moving the mouse from the Taskbar to one of the tab previews.
We could probably find a hack-like way do this via a new mouse hook dll on the taskbar.  We'd have to figure out our position on the taskbar though.  
It seems that in Win7 the whole taskbar button list is a single window class with no child windows: MSTaskListWClass.  Earlier Windows versions would have allowed us to enum the child windows to get the taskbar button and hence figure out our location easily.

But there are problems with the idea of click to activate when there are tab previews...
What happens if taskbar previews is ON and the user has 2 windows. The first window has 5 tabs, the second window has 1 tab.  Then the user clicks the taskbar icon.  What do we do? 

When taskbar previews are OFF and we have multiple windows we will bring up the previews of the 2 windows on taskbar icon click. Even Google Chrome works this way.  Should multi-windows also act in this way bringing up one of the 2 windows? Probably not because then the user has to realize they aren't in the correct window at all.  Should multi-window and multi-tab functionality differ? I would be confused why sometimes I click and it brings up previews but other times I click it brings up the window. 

> When the user just wants to bring Firefox to the front (perhaps to get a full view of the active tab), they need to identify the active tab in the set of aero peek thumbnails.

Maybe the solution here is to make the active tab easier to identify.  If so I'd love to hear any ideas of how it should look.

> Also, if the user wants to create a new tab, they need to select which of their existing tabs...

We could do Windows 7 tasbar action buttons on the preview window(s).
See here: http://www.brianbondy.com/static/img/blogpost_111/Windows7ThumbnailPreviews.png
I posted Bug 685736 because even when this is implemented it would be nice to know what the active tab is on delayed hover.  I also posted Bug 685739 to investigate new tab functionality from the previews itself.
Priority: -- → P3

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.