516249 - [10.6] Wrong event modifiers passed to plugin on switching Spaces with Ctrl-<number key>

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Jürgen Kreileder]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090913 Firefox/3.5.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090913 Firefox/3.5.4

After switching to a Space with a Firefox window containing a Flash movie by using Ctrl-<number key>, wrong event modifiers get passed to Flash: Left-clicking (without any modifier held) acts like Ctrl was still pressed => the click opens Flash's context menu.
To get normal left clicks in Flash recognized as just normal left clicks again, you have to press another modifier (Ctrl, Option, Shift, Cmd) before clicking.

The problem does not show up with Flash in Safari.  It also does not show up in other areas of the Firefox window, only embedded Flash is affected.

Reproducible: Always

Steps to Reproduce:
1. Enable Spaces
2. Enable direct switching to Spaces with ^-<number key>
3. Open a Flash movie in Firefox
4. Switch to another Space with ^-<number key>
5. Switch back to the Space containing the Firefox window with Flash by ^-<number key>
6. Release any keys
7. Make sure the Firefox window got focus (if you have to click the window to give it focus first, the problem doesn't show up)
8. Click on the Flash movie
Actual Results:  
Flash's context menu opens (like for right-clicks, or ctrl-left-clicks)

Expected Results:  
The click gets passed as what it is: a normal left-click without any modifiers

Comment 1

[Tanner Filip [:tanner]]

Yep, it may be a dupe of Bug 78414

Comment 2

[Tanner Filip [:tanner]]

*Yep, i can reproduce

Comment 4

[Jürgen Kreileder]

I don't agree that this is a duplicate of bug 78414.  This problem is not about Flash blocking access to application shortcut keys, it's about wrong events being sent to Flash.

The problem is relatively new, it either got introduced with a recent nightly or by the upgrade to Snow Leopard.

Comment 5

[Dave Townsend [:mossop]]

This has been bugging me every since upgrading to 10.6

Comment 6

[Tanner Filip [:tanner]]

I can reproduce in Vista too...

Comment 7

[Jürgen Kreileder]

How did you reproduce that on Vista?  Ctrl + left-click isn't a popup trigger on Windows (nor on Linux).

Comment 8

[Sam Tucker]

Me too; Firefox 3.5.3 and the latest Flash 10.0.32.18 on Mac OS X 10.6. I also disagree with marking this a duplicate of bug 78414; this is a separate issue.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

I'll get to this next week (probably Monday).  But in the meantime could someone test (on OS X) with my DebugEventsPlugin from bug 441880?

Comment 10

[nevermadness]

can also reproduce on camino, os x 10.6

Comment 11

[Chris Lawson (gone)]

Has anyone tried this with any plugins besides Flash?

Comment 12

[Jürgen Kreileder]

Yes, everything but the Java plug-in shows the same problem: Quicktime, Flip4Mac, Silverlight, ...

Comment 13

[Matt Bramlage]

I can confirm on Snow Leopard (10.6.1) and Firefox (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3). This is especially irritating to me as I am a developer who works with a Flash frontend to our cloud computing app; Firebug is far and away the best development tool out there (we can see the HTTP transport, which is _great_). Spaces is also great, because I'll often have Firefox, Eclipse, a shell, and a virtual machine open at the same time at a minimum. However, if I can't e.g. click on anything, that kind of defeats the purpose.

A workaround is to _not_ use keyboard shortcuts to switch spaces; if you use e.g. the keyboard shortcut to "activate spaces" and get the zoomed-out view, and click on the desired space, you're fine. Switching to a different space and back again with the "zoom out" method will cause the plugin to become "unstuck". I suspect if you remap the keyboard shortcut for spaces to something more benign, this would also do it (though, presumably, the keyboard modifiers are still in effect, they may be ignored).

Comment 15

[Steven Michaud [:smichaud] (Retired)]

I've confirmed this using my DebugEventsPlugin (testing with FF 3.5.3
and today's Minefield, Namoroka and Shiretoko nightlies on OS X
10.6.1).

Strangely, the problem happens even when the plugin isn't in the
current tab, or even the currently focused browser window (on
switching to and from another space (using ^-<number key>)).

You can make the problem stop happening by 1) doing a
ctrl-left-mouse-down (though not a right-click) anywhere in any FF
browser window or 2) by clicking on the desktop (or another app's
window), then clicking on one of the FF browser windows.

If the plugin is in the currently focused tab (in the currently
focused browser window), it also receives a loseFocus event when
switching to another space and a getFocus event when switching back.
(This doesn't happen in Safari.)  But this isn't enough (by itself) to
cause the problem, and also happens on OS X 10.5.8.

Though there must be some kind of OS involvement here (since the
problem only happens on OS X 10.6.X), this is pretty clearly a Mozilla
bug.

Comment 17

[Samer Ziadeh]

The same issue happens to Komodo Edit, when I switch back to Komodo I cannot click unless I control+click and then my clicks can be restored.

I happened to me ever since I upgraded to Snow

Comment 18

[Samer Ziadeh]

You don't have to control+click to "reactive" it, if I just press control then it just restores the click to it.

It's like as if when I press control+arrows or control+<workspace#> the "space switcher" key is stuck there.

did i make sense?

Comment 19

[Steven Michaud [:smichaud] (Retired)]

> You don't have to control+click to "reactive" it, if I just press control
> then it just restores the click to it.

I see the same thing.

> did i make sense?

Yes.

Comment 20

[Samer Ziadeh]

could it be that it's a Snow bug?

Comment 21

[Steven Michaud [:smichaud] (Retired)]

> could it be that it's a Snow bug?

No, I think it's unlikely to be a SnowLeopard bug.  More likely FF is reacting badly to unexpected behavior from SnowLeopard.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix

I was wrong -- this *is* a SnowLeopard bug:

On SnowLeopard GetCurrentEventKeyModifiers()
(http://developer.apple.com/legacy/mac/library/documentation/Carbon/Reference/Carbon_Event_Manager_Ref/Reference/reference.html#//apple_ref/doc/uid/TP30000135-CH1g-DontLinkElementID_15)
returns the wrong result after following the STR from comment #0, and
keeps doing so until you press (and release) one of the following keys
-- Control, Option, Command, Shift, CapsLock.

WebKit kit doesn't have this problem.  The reason why is that WebKit
uses GetCurrentKeyModifiers() (instead of
GetCurrentEventKeyModifiers()), which doesn't have the bug.

The difference between these two functions is that
GetCurrentEventKeyModifiers() returns "the modifier state according to
the event most recently dispatched through an event target", while
GetCurrentKeyModifiers()
(http://developer.apple.com/legacy/mac/library/documentation/Carbon/Reference/Event_Manager/Reference/reference.html#//apple_ref/c/func/GetCurrentKeyModifiers)
indicates "which modifier keys are pressed" (the current hardware
state).

The patch for bug 320746 globally replaced calls to
GetCurrentKeyModifiers() with calls to GetCurrentEventKeyModifiers().
In principle the latter method sounds more appropriate for our
purposes (at least for most of them).  But it's difficult to find
practical circumstances in which using GetCurrentEventKeyModifiers()
makes any difference (for example GetCurrentEventKeyModifiers()
doesn't support event scripting, since it ignores events arriving from
outside the application).

So I think we should (mostly) reverse the patch for bug 320746 -- as
my patch does.

I've left alone the call to GetCurrentEventKeyModifiers() in
XRE_main() (which was the original focus of bug 320646).  Since that
call happens on startup, it's unlikely to be effected by the 10.6 bug
in GetCurrentEventKeyModifiers().

In principle we might use GetCurrentKeyModifiers() only if we're on
10.6 or higher.  This is a reasonable fallback ... but I don't think
it's really necessary.

I'll report this bug to Apple as soon as I can write a simple Cocoa
app that demonstrates it.

A tryserver build will follow in a few hours.

Comment 23

[Josh Aas]

Comment on attachment 402855 [details] [diff] [review]
Fix

Looks good to me, seems like "nsAppRunner" is the only consumer that needs to use event-based checks.

Comment 24

[Steven Michaud [:smichaud] (Retired)]

Landed on trunk:
http://hg.mozilla.org/mozilla-central/rev/8b4d2fc47ecf

Comment 25

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 402855 [details] [diff] [review]
Fix

We should probably land this on the 1.9.2 branch after baking for a
few days.  It also (I think) should get onto the 1.9.1 and 1.9.0
branches.

FF 3.5.4 and 3.0.15 were code-frozen a few days ago (9-22).  Though
this bug is pretty bad, I'm not sure it's urgent enough to land on
those branches after the code freeze.

Comment 26

[Steven Michaud [:smichaud] (Retired)]

My patch will appear in tomorrow's mozilla-central nightly (and subsequent ones).  But (for what it's worth) here's the tryserver build I promised above:

https://build.mozilla.org/tryserver-builds/[e-mail]-bugzilla516249/bugzilla516249-macosx.dmg

Comment 27

[Daniel Veditz [:dveditz]]

Comment on attachment 402855 [details] [diff] [review]
Fix

Please re-request 1.9.0/1.9.1 branch approval after this has landed and been tested on 1.9.2

Comment 28

[Steven Michaud [:smichaud] (Retired)]

Landed on the 1.9.2 branch:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/259e824613ea