Closed Bug 312920 Opened 18 years ago Closed 6 years ago

Key.isDown not showing keypresses in Flash plugin when wmode is set to anything but window


(Core Graveyard :: Plug-ins, defect)

Windows XP
Not set


(Not tracked)



(Reporter: netdragon, Unassigned)



(4 files, 1 obsolete file)

If you create a Flash object, and use the key.isDown() function, and hold down
the left or right keys, the Flash object isn't receiving the keypresses if the
wmode attribute is set to anything but "window".

Affects Firefox/Win 1.0.7 but doesn't affect Firefox/Mac, Safari, or Internet
Explorer on Windows. It does affect Opera 8 / Win. Therefore, it might be a
windowing issue related to the Flash plugin.

* Changing the format of the object tag has no affect.
* Clicking in the Flash object to give it focus has no affect

Here is the Flash actionscript:

bg_mc.onEnterFrame = function(){
  if (Key.isDown(Key.LEFT)) {;
  if (Key.isDown(Key.RIGHT)) {;

Debugging the C++ plugin code might be necessary to track this down.
The .fla inside the zip contains a copy of the actionscript. It also has a key
listener that doesn't have the same issue.

Click on the Flash object to ensure focus, and hold down the left or right key.

You should see the following behavior:
* onEnterFrame blinks when wmode=window
* onEnterFrame doesn't blink when wmode equals anything else

The HTML files are named accordingly.
Attached file swf used by following htmls (obsolete) —
Comment on attachment 199987 [details]
swf used by following htmls

Note that if you view this directly, wmode=window is the default.
Attachment #199987 - Attachment description: swf demonstrating the issue → swf used by following htmls
Attachment #199987 - Attachment is obsolete: true
Attached file Demonstrates issue
Click on it to ensure focus, then hold down left or right key.

Expected behavior: both the top and bottom text on each side Flash (View in IE)

Actual behavior: only bottom text flashes (from key listener)
This demonstrates wmode=window, and flashes both top and bottom on each side as
opposed to the above (wmode=transparent) that only flashes the bottom text.
Keypress events seems to be intentionally consumed.
Should we have the way for plug-ins to get keypress events when they are required?
These test cases show the issues with key combos like 'shift-a' and 'control-a' as well as 'shift-click'.  The FLA file is included.
This bug still exists on FF Windows  The issue extends to any key combo with shift or control including mouse actions.  
Masatoshi Kimura: what does it mean 'intentionally consumed' ?  Is there a reason that they should be?  or are you just stating that the code works that way.  Seems like a bug to me...
this bug (as I agree with Sarah) is also at fault for making the mouse scroll wheel events not get passed to flash.  I do not see anything in the code that says that this is the desired behavior.
This is still happening in FireFox
-'ing since it is not a regression.  Nice to have a fix if someone should produce one.
Flags: blocking1.9? → blocking1.9-
As a temporary fix until it gets unbugged.. i've used a javascript key trap that uses Flash's ExternalInterface to pass the keystrokes into flash. I don't know if that would help anyone for the time being.
That's creative but our Flash like most Flash's has many different focusable views - can you use this method to pass the keystroke events to whichever view is focused?
By the way we would be interested in hiring someone to fix this if anyone with appropriate skills is interested.

Regarding your workaround - we have different views having focus in the Flash.  Can JavaScript catch the key strokes even when Flash has focus if that question makes sense?


Hi Zvi,

it depends what you mean exactly? i found that the problems i was getting weren't todo with all keypresses - just using Key.isDown()... i also found that there were weird focussing issues between multiple flash embeds in a webpage when using wmode=opaque or transparent (you wouldn't be able to refocus the movie without having focused on the html page first - have a play with focusing between the movies in my testcase and you'll see what i mean).

The system i was building at the time was a tree-view component so shift & ctrl were both quite important for multiple selection of items - i used javascript (window.onkeydown & window.onkeyup - well the add handler equivalent to do things properly) just to register when shift or ctrl were (un?)pressed and fired my own event handler within the Flash that would keep it's own track as to the state of shift or ctrl. I then used this inplace of Key.isDown() and it seemed to work quite well.

An example of exactly what happens - and may answer your question can be found here:

you can indeed trap javascript whilst focussed on an opaque or transparent movie

Hope that helps?
We will have to play with it - many thanks for the tips
I agree that this seams to be a problem with the flash plugin rather than Mozilla. I see the problem in other NPAPI browsers including Opera and Safari for windows.
Michelle from the Flash Player team here.... I don't reproduce the problem described in Comment #4 or Comment #7 with Win Firefox and Flash Player 9r115 (the latest release). Does this mean the bug is fixed? If no, what are the repro steps? Thanks.
the Key.isDown() does seem to be fixed for me when i test using my previous example. As all movies are reporting true at the onKeyDown point. I haven't checked specifically what #4 and #7 have described but it looks to be the same issue. However Flash does still seem to get confused as to what Movie is focused. If you go here:

And click around between movies (mainly between the top left movie - running in window mode - and the other two adjacent - you should get to a point where you can't focus on the opaque or transparent windows without first having to select an area of the HTML page. Not a huge problem - and not i guess to do with this bug - but something still worth noting.. nice work on fixing the other issue however :)
Hi Michelle -- thanks for checking into this.

We ran some initial tests with german language on one machine, and while the keyDown event is received there is still a problem. Now when a special character is entered in german it seems to register the english sequence instead whereas previously it wouldn't enter any character at all. For example, when I type shift-6 on a german keyboard I expect to see a "&" but instead I see a "^". In IE this test works fine, and I do get an "&" character.   We plan to do further testing to validate our results, but I thought I would note what we have found so far.

We'll re-run with the original test case that Michael Gregor reported and see if we can repro with that simple case.
This bug is fixed.  The issue I noted above is already described in Bug 347185 (
This bug is not fixed.
It is still reproducing the wrong character when you have wmode != window and a non-us keyboard.
I have a Swedish keyboard. When i type something in a textfield contained in a flashplayer with wmode = "window" it is ok. For example i press "SHIFT++" wich gives me "?".
If i run the same test but window = "opaque" or window = "transparent" i dont get "?", i get "+".
The same thing occurs with ALT combinations.

This is a serious bug that has been here way too long. This needs to get your attention.
Window Mode transparent and Opaque is often a must when creating flash films, and this disadvantage is abnormal!

There are some fixes, real ugly ones.
Like changing the character after it's been inserted, trapping keys in javascript then inserting them to flash, or put characters that need to be used in the field from the start.

None of them is good, they are all just a small plaster on one big wound!
As it stands, I'm not sure whether we fixed this. But as Flash is moving into legacy mode, changing this now would probably cause more regressions than it fixes, so I'm not going to accept a patch even if one appears.
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.