605338 - Turn off Aero Peek until we can implement a delayed hover

Status: RESOLVED FIXED

(Firefox :: Shell Integration, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

This is a mitigation step until we can address bug 586155.  Copying over details for the change:

>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).

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Nominating for blocking so we can make a decision.

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

Note, if we don't block on this bug, then we need to block on bug 607154

Comment 3

[Kevin Hanes]

Any word on if this is a blocker? It would take care of bug 581726 in Panorama (as long as we don't land bug 586155 as well). The fix on our end is pretty non-trivial.

Comment 4

[Rob Arnold [:robarnold]]

(In reply to comment #3)
> Any word on if this is a blocker? It would take care of bug 581726 in Panorama
> (as long as we don't land bug 586155 as well). The fix on our end is pretty
> non-trivial.

By turn off, we just mean flip the default pref. There's a GUI option for it (because some users really like it) so I think bug 581726 will need to be fixed either way.

Comment 5

[Jim Mathies [:jimm]]

(In reply to comment #3)
> Any word on if this is a blocker? It would take care of bug 581726 in Panorama
> (as long as we don't land bug 586155 as well). The fix on our end is pretty
> non-trivial.

Bug 586155 really should be marked wontfix. The feature requests there aren't possible with the current set of underlying taskbar apis. So tab candy/taskbar preview bugs shouldn't block on it.

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

Note for triage: we need to block on this due to bugs 581726 and 538487

Comment 7

[Benjamin Smedberg]

Jim, can you flip the pref off?

Comment 8

[Joe Drew (not getting mail)]

Bug 556524 is caused by Aero Peek; we think we might have fixed it, but won't know until we get more crash-stats data.

Comment 9

[Jim Mathies [:jimm]]

Attachment: switch

Comment 10

[Jim Mathies [:jimm]]

http://hg.mozilla.org/mozilla-central/rev/a2b4d0911bb0

Comment 11

[Chris B.]

Not sure what "Turn off Aero Peek until we can implement a delayed hover" means, but I would like to state that if Tab Preview is turned on and you hover your mouse over the preview for www.cisco.com, the entire Minefield window turns black.

Comment 12

[u88484]

(In reply to comment #11)
> Not sure what "Turn off Aero Peek until we can implement a delayed hover"
> means,
The feature when you click on a taskbar item on Windows 7 (the preview of the active and inactive tabs).

> but I would like to state that if Tab Preview is turned on and you hover
> your mouse over the preview for www.cisco.com, the entire Minefield window
> turns black.
This would be a separate bug.