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

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Brian 'netdragon' Bober]

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)) {
    left_clip_mc.play();
  }
  if (Key.isDown(Key.RIGHT)) {
    right_clip_mc.play();
  }
}

Debugging the C++ plugin code might be necessary to track this down.

Comment 1

[Brian 'netdragon' Bober]

Attachment: Zip of files pertaining to issue

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.

Comment 2

[Brian 'netdragon' Bober]

Attachment: swf used by following htmls

Comment 3

[Brian 'netdragon' Bober]

Comment on attachment 199987 [details]
swf used by following htmls

Note that if you view this directly, wmode=window is the default.

Comment 4

[Brian 'netdragon' Bober]

Attachment: 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)

Comment 5

[Brian 'netdragon' Bober]

Attachment: Demonstrates expected behavior

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.

Comment 6

[Masatoshi Kimura [:emk]]

Keypress events seems to be intentionally consumed.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsObjectFrame.cpp&rev=1.525&root=/cvsroot#3323
https://bugzilla.mozilla.org/show_bug.cgi?id=122501
Should we have the way for plug-ins to get keypress events when they are required?

Comment 7

[Michael Gregor]

Attachment: Better Zip of test cases. Has readme

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.

Comment 8

[Michael Gregor]

This bug still exists on FF Windows 1.5.0.1.  The issue extends to any key combo with shift or control including mouse actions.  

Comment 9

[Sarah Allen]

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

Comment 10

[Michael Gregor]

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.

Comment 11

[Phil Glanville]

This is still happening in FireFox 2.0.0.1

Comment 12

[Zvi Schreiber]

These seem to be related:
https://bugzilla.mozilla.org/show_bug.cgi?id=347185
https://bugzilla.mozilla.org/show_bug.cgi?id=312920
https://bugzilla.mozilla.org/show_bug.cgi?id=306473
https://bugzilla.mozilla.org/show_bug.cgi?id=347185
https://bugzilla.mozilla.org/show_bug.cgi?id=389678
https://bugzilla.mozilla.org/show_bug.cgi?id=401440

Comment 13

[Damon Sicore (:damons)]

-'ing since it is not a regression.  Nice to have a fix if someone should produce one.

Comment 14

[Phil Glanville]

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.

Comment 15

[Zvi Schreiber]

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?

Comment 16

[Zvi Schreiber]

By the way we would be interested in hiring someone to fix this if anyone with appropriate skills is interested.

Comment 17

[Zvi Schreiber]

Phil

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?

Thanks

Zvi

Comment 18

[Phil Glanville]

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:

http://www.unabacus.net/testcases/FlashKeyProblem/

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

Hope that helps?

Comment 19

[Zvi Schreiber]

We will have to play with it - many thanks for the tips

Comment 20

[Lorien Henry-Wilkins]

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.

Comment 21

[Michelle Sintov]

Michelle from the Flash Player team here.... I don't reproduce the problem described in Comment #4 or Comment #7 with Win Firefox 2.0.0.12 and Flash Player 9r115 (the latest release). Does this mean the bug is fixed? If no, what are the repro steps? Thanks.

Comment 22

[Phil Glanville]

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:

http://www.unabacus.net/testcases/FlashKeyProblem/

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

Comment 23

[Sarah Allen]

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.

Comment 24

[Sarah Allen]

This bug is fixed.  The issue I noted above is already described in Bug 347185 (https://bugzilla.mozilla.org/show_bug.cgi?id=347185)

Comment 25

[Marc Oldway]

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!

Comment 26

[Benjamin Smedberg]

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.