All users were logged out of Bugzilla on October 13th, 2018

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

RESOLVED WONTFIX

Status

()

--
major
RESOLVED WONTFIX
13 years ago
2 years ago

People

(Reporter: netdragon, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
Created attachment 199986 [details]
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.
(Reporter)

Comment 2

13 years ago
Created attachment 199987 [details]
swf used by following htmls
(Reporter)

Comment 3

13 years ago
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
(Reporter)

Comment 4

13 years ago
Created attachment 199989 [details]
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)
(Reporter)

Comment 5

13 years ago
Created attachment 199991 [details]
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.
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

13 years ago
Created attachment 216759 [details]
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

13 years ago
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

13 years ago
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

13 years ago
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

12 years ago
This is still happening in FireFox 2.0.0.1
-'ing since it is not a regression.  Nice to have a fix if someone should produce one.
Flags: blocking1.9? → blocking1.9-

Comment 14

11 years ago
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

11 years ago
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

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

Comment 17

11 years ago
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

11 years ago
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

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

Comment 20

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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

2 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.