Last Comment Bug 347185 - when using wmode="transparent" for flash movie, german keyboard produces english characters
: when using wmode="transparent" for flash movie, german keyboard produces engl...
Status: RESOLVED FIXED
: intl
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86 Windows XP
: P1 major with 65 votes (vote)
: mozilla6
Assigned To: Masayuki Nakano [:masayuki] (Mozilla Japan)
:
:
Mentors:
http://www.bannerscreen.com/bannercre...
: 306473 313880 338797 356972 389678 401440 413822 457673 586939 643276 660772 (view as bug list)
Depends on: 272847 478862 651694
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-03 08:44 PDT by masa
Modified: 2013-12-27 14:35 PST (History)
72 users (show)
pavlov: wanted‑next+
dsicore: wanted1.9.1+
pavlov: blocking1.9-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed


Attachments
Matrix of Browser/Flash/OS versions for reproducibility of bug (358 bytes, text/plain)
2008-03-05 07:11 PST, Timothy Soehnlin
no flags Details
AS2 Fix class (2.53 KB, application/octet-stream)
2008-06-19 01:32 PDT, Marc Oldway
no flags Details
Patch v1.0 (1.13 KB, patch)
2011-04-18 01:20 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
bugs: review+
roc: review+
Details | Diff | Splinter Review
Tests v1.0 (14.66 KB, patch)
2011-04-19 23:01 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
roc: review+
Details | Diff | Splinter Review
Patch v1.0 (mq) (700 bytes, patch)
2011-04-20 16:47 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
asa: approval‑mozilla‑beta+
christian: approval2.0-
Details | Diff | Splinter Review
Tests v1.0 (mq) (10.15 KB, patch)
2011-04-20 16:48 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details | Diff | Splinter Review

Description masa 2006-08-03 08:44:39 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5

I used wmode="transparent" in <object> and <embed> tag for a flash movie in HTML.
While testing the page (using a german keyboard) and filling in form data in the flash movie, I encountered the problem that some characters were wrong. It seems that english keyboard characters appear. Only special characters seemed to be affected like @ or $ or ^.
In IE6 it worked fine.


Reproducible: Always

Steps to Reproduce:
1.open http://www.bannerscreen.com/bannercreator.htm
2.type in some special characters like @ or $ in one of the input fields (happens with german keyboard)
3.
Comment 1 Frank Wein [:mcsmurf] 2006-08-04 03:26:08 PDT
I can confirm this with the Flash 8 and Flash 9 plugin with Firefox 1.5 and a current SeaMonkey trunk build.
jmott: I think this bug here is a possible bug in the Flash plugin.
Comment 2 Jeff Mott 2006-08-04 09:27:23 PDT
We have several open bugs on this in the player bugbase.  I went back to look at my old notes, and here's what I wrote about a similar issue with French and Japanese:

[jmott 12/2/04] Adding info about French problems - some characters (like %, | or >) just can't be typed. For example, '%' is supposed to be generated where '"' is on the english keyboard

Netscape - NPP_HandleEvent does not forward WM_IME_*. FOL - Bugzilla bug 272847.

[jmott 12/2/04] Windows IME not displaying is FOL per Microsoft tech support - we went around with this back in 2002.

Investigating french keyboard input not working.
[jmott 12/2/04] French issues are Netscape only!
[jmott 12/2/04] French issues due to NPP_HandleEvent not forwarding WM_CHAR - we fake WM_CHAR in WM_KEYDOWN.
[jmott 12/2/04] This is also FOL, and I've added it to the bugzilla bug. The only way around this is to code up a custom shift table for every language we support, which just doesn't seem worth it.
Comment 3 lime 2007-02-22 00:37:01 PST
I can confirm this for FF 2.0.1 and flash player 8 & 9 on Win XPsp2.
Using wmode transparent or opaque seems to change italian keyboard to english keyboard
Comment 4 Phil Ringnalda (:philor) 2007-02-26 23:01:03 PST
*** Bug 338797 has been marked as a duplicate of this bug. ***
Comment 5 Mimidou 2007-03-01 05:20:09 PST
I confirm

In FF 1.5.0.10 is the same thing
Comment 6 Adam Guthrie 2007-07-26 14:32:15 PDT
*** Bug 389678 has been marked as a duplicate of this bug. ***
Comment 8 Damon Sicore (:damons) 2007-11-15 12:04:56 PST
-'ing since it is not a regression.  Nice to have a fix if someone should produce one.
Comment 9 Mike Schroepfer 2007-12-15 09:32:23 PST
I've gotten recent reports that:  http://www.gmx.net/de/, which has tents of millions customers, is having trouble with their flex-based mail client and believes it might be released to this.   Can we take a second look at this for FF3?

Comment 10 Carsten Book [:Tomcat] 2007-12-15 14:29:48 PST
(In reply to comment #9)  Can we take a second look at this for
> FF3?
> 

I have done some tests with a test gmx account and have tested the current GMX Mail Client and a new version called GMX 2007 (beta).

Firefox 2.0.0.11 is fine on both UI's - no problem with the current and Beta UI and german keyboard

Firefox 3 Beta 2 is also also fine and i can write/send mails and using the german keyboard. There is a unrelated issue with Firefox 3 Beta 2 and some special layout features (like bold fonts etc) in the UI beta version and i will send this to GMX.

Trunk works also fine on the current GMX Mailclient UI
Comment 11 Peter Blaha 2007-12-17 12:19:00 PST
I have tried it with the German version of Firefox 3 Beta on a German keyboard. The result is the same as in the privies version. 

In wmode = default 
I am able to typ the @ sign and other high ASCII characters (works as expected)

In the wmode = opaque and wmode = transparent 
I still have the same problems.

I can not typ the special characters which need the shift key or ALT Gr key pressed.

The result is like I wouldn’t press the shift or ALT Gr at all. Otherwise it does recognize the other keys of the German keyboard correct. 

Comment 12 Jeff Mott 2007-12-17 13:01:08 PST
We still have the original problem, which causes this bug and bug 272847.  When the control is running with wmode = opaque or wmode = transparent Firefox stops dispatching WM_CHAR (and WM_IME_*) events which the player depends on.  See the test case provided for 272847 - Neither German ALT Gr input nor IME based input works.
Comment 13 Damon Sicore (:damons) 2007-12-17 15:10:36 PST
+'ing with P2.  Johnny, can you take a look at this?
Comment 14 Jeff Mott 2008-01-08 16:03:07 PST
Is there any progress or prospect of progress on this bug?  Flash Player would dearly love to see this working.  Thanks!
Comment 15 Xavier Daleau 2008-01-22 07:56:51 PST
Please ! It's been a major bug of Firefox for years, simply search for "firefox wmode bug" on Google and you'll realize that the whole Flash development community is waiting for it to be solved. Thanks.
Comment 16 Eyal Peleg 2008-01-27 05:18:58 PST
This is a BIG issue.
you can not enter an email address as you would expect using a german/frensh/other non standard keyboard.

note however that pressing shift+2 does add the @ symbol.
Comment 17 Robert 2008-02-09 12:15:53 PST
Would love to see this fixed in FF3.
This has been around for such a long time.
Come on - do it!
Cheers
Comment 18 Sarah Allen 2008-02-28 07:18:51 PST
There is a good test case here: https://bugzilla.mozilla.org/attachment.cgi?id=237019
(This was in a bug that was marked a dup of this one)  The problem happens for other wmodes, but I forget which ones.  (Will look into later, unless someone else chimes in first.)
Comment 19 Zvi Schreiber 2008-02-28 07:34:21 PST
This is NOT fixed - I just checked with the latest FireFox (2.0.0.12 - I didn't try v3).  You can try it at our site http://g.ho.st (specifically the service at http://g.ho.st/vc.html) - I am trying a Hebrew keyboard and all characters come out in English (for example ask for a password reminder then you get an edittext where you can type Hebrew chars in IE but not in FF
Comment 20 Frank Wein [:mcsmurf] 2008-02-28 08:18:24 PST
Zvi: That is why this bug is marked as NEW. We know it is not fixed yet.
Comment 21 Timothy Soehnlin 2008-03-05 07:06:02 PST
I have tested this bug with different versions of Flash and Firefox all using a French Keyboard Layout.  

Flash Version	Browser              	OS	        Fail
9.0.115	                Firefox 2.0.0.12	Mac	
9.0.47	                Firefox 2.0.0.10	Win XP	x
9.0.115	                Firefox 2.0.0.12	Win XP	x
9.0.47	                Firefox 2.0.0.11	Vista	x
9.0.115	                Firefox 2.0.0.11	Vista	x
9.0.115	                Firefox 2.0.0.12	Vista	x

Everything bug Mac seems to fail, and all browsers that fail, fail in the same way. 
Comment 22 Timothy Soehnlin 2008-03-05 07:11:28 PST
Created attachment 307472 [details]
Matrix of Browser/Flash/OS versions for reproducibility of bug

A matrix of information on browser/flash/os version combinations and the reproducibility of this bug.
Comment 23 Molokoloco 2008-03-25 11:45:45 PDT
Can do nothing ?
Comment 24 yann 2008-04-17 07:22:00 PDT
Still not fixed!!!
In fact, key combinaisons are not detected.

This is really a hudge bug for all the flash community, please correct it quickly!
Comment 25 Kstor 2008-04-17 07:45:51 PDT
Fix this huge bug !!!!
i wonder if i should say please ?.... after 2 years ...
this is a major bug for everyone.
Comment 26 Sci-Fi Si 2008-06-08 12:00:37 PDT
In reply to comment #10, I'm sorry to say that this bug has not actually been fix in any version of firefox including the current 2.0.0.14 or even the new FF3. I have no idea how you can say that it has? Do you have any idea what we are actually talking about here?

wmode=transparent seems to switch the keyboard to a standard US layout - not UK which is why the @ symbol is only displayed with 'Shift and 2'

It would appear that the programmers of this browser simply don't care how badly or slowly Flash is rendered, and after many years of having this problem
, thousands of complaints posted on the internet and at least half a dozen new releases of FF that still don't have a fix for this bug, it can only mean one of the following:

None of their programmers know how to fix this problem because their too stupid, or none of the programmers care that their browser doesn't work with the world's most important Internet animation tool.

I hope this comment has annoyed someone at Mozilla sufficiently enough to actually do something about this problem that has now been dragging on for years.

[Options]
Have an email textfield="@" to put the character there in the first place (which looks very tacky)

Don't use wmode at all (Which makes the form look very uninteresting)

Have a message displaying "This website is best viewed in Internet Explorer" (Which I think is a much, much better browser in every way, even though I dislike Microsoft as much as the next man but, IE makes FF look like the slow, buggy, patchy, flakey, rubbish that it is.

:)
Comment 27 Sci-Fi Si 2008-06-08 12:23:21 PDT
Oops! Sorry about the typo where 'been fix' should read 'been fixed'

P.S.

I will see if I can get a copy of the full source code for Firefox and fix this @@@@ing bug myself, or should that be """"ing bug myself! LOL!

:)
Comment 28 Tek 2008-06-08 12:25:04 PDT
I totally agree with Sci-Fi SI, this bug is not fixed nor with french, german or any other non US keyboard layout with wmode=transparent or wmode=opaque with Flash plug-in.
Comment 29 Marc Oldway 2008-06-19 01:32:57 PDT
Created attachment 325720 [details]
AS2 Fix class

A fix that temporarily fixes this BUG (IN AS2!!!)
Comment 30 Marc Oldway 2008-06-19 01:36:01 PDT
The attachment above is a temp. fix for the problem (AS2)
All you need to do is create an inctance of it in your movie (anywhere) and it will take care of the rest.
It will automatically fix most characters (hopefully all) in all textfields.
The change occurs after the user releases a key, which makes for a glich. You can see the actual change happen. But that is something you will have to live with.
The characters are changed into the Swedish keyboard.
Should be pretty straight up to change it to you language!
Comment 31 Tek 2008-06-19 04:16:28 PDT
(In reply to comment #29)
> Created an attachment (id=325720) [details]
> AS2 Fix class
> 
> A fix that temporarily fixes this BUG (IN AS2!!!)
> 

Do not tell Mozilla this is a fix because it is not ... keep actionscript with actionscript, Mozilla development with Mozilla development.

The class you upload is not a fix but an helper to correct some wrong typed characters in some language only. Their is plenty of keyboard layout all around the world, we cannot use a huge class with all charmap for all languages.
Comment 32 IcePanther 2008-06-26 11:27:02 PDT
Confirmed on FF3 on Vista Business (FR).

When my Flash movie is set to Opaque or Transparent in the wmode, entry fails, can't detect simultaneous ALT or SHIFT + a key. For an eMail entry form, it's bad.
Also happens in Opera (which uses the same plugin).
IE is spared.

(plugin problem, anyone ?)

Annoying since, as Tek said, a class with all possible keyboard matrixes (plus a logic allowing to select yours) would be awful to program, and I'm not even speaking about the VK "workaround", even more awful.
Comment 33 astgtciv 2008-08-23 22:07:56 PDT
Here is my attempt at a workaround for this: http://analogcode.com/p/JSTextReader/ . Reroutes input flow via javascript (which is not affected by the browser/flash bug of course), works with most keyboard layouts (more complicated ones like Japanese appear beyond salvation). Works for the FF version of this bug and its IE  ("strange characters") manifestation as well. 
Comment 34 Patrick Tai 2008-08-25 14:30:33 PDT
The AS2 class is not a fix as it limits some character inputs and this is not usable on a text field where the user is allowed to enter free text. It might be fine for one country but websites are viewed by people all over the world so trying to map the key codes to a specific country keyboard layout is simply not realistic. 

For the current project I'm working on - 13 languages -, I had to do a JS browser detection to remove the wmode parameter from the swf settings in the embed and objet tags for FF3. 
No one was aware of this bug and it has caused some stress to my client, the people I work with and a waste of time and money for all of us. Not to mention that my client might look somewhere else for his next flash based project. 
Now, the design of the background is simply a solid color for FF3 users. I can't  imagine all the headaches when a javascript menu has to appear on top of the flash content, luckily for my client and me it's not the case here, but I know that it is a common one eg. Adobe's website.

It's not expected from a popular browser to have such HUGE bugs and cause so many troubles to the Flash community of users and developers. I hope that this bug and all the ones affecting the usage of Flash content within Firefox 3 will be assigned ASAP so they can be fixed very quickly and once for all. For the time being I can only tell to everyone I know NOT to install FF3 or to use another browser.

Comment 35 Johnny Stenback (:jst, jst@mozilla.com) 2008-08-25 22:01:00 PDT
Patrick, if you know someone who is familiar with this issue and would be able to help fix this in the Firefox code please do ask if they could help out here. Any help would be greatly appreciated!
Comment 36 Sarah Allen 2008-08-25 22:37:56 PDT
I think this is a Flash Player bug, not a Firefox bug.  I believe that it has the same root cause as https://bugzilla.mozilla.org/show_bug.cgi?id=312920 which has been seen on other browsers that use the Flash plugin -- see comment https://bugzilla.mozilla.org/show_bug.cgi?id=312920#c20 
Comment 37 Jeff Mott 2008-09-02 10:59:10 PDT
Please check the earlier comments.  The root issue is that when the player is in windowless mode, we do not recieve WM_CHAR events from Firefox.  We simulate them based on key down events, which is why we loose the keyboard mapping.  Someone needs to change Firefox so that it will send us WM_CHAR events in windowless mode.
Comment 38 Matthias Versen [:Matti] 2008-09-19 18:19:03 PDT
*** Bug 356972 has been marked as a duplicate of this bug. ***
Comment 39 Matthias Versen [:Matti] 2008-09-19 18:19:22 PDT
*** Bug 413822 has been marked as a duplicate of this bug. ***
Comment 40 Matthias Versen [:Matti] 2008-09-19 18:19:53 PDT
*** Bug 313880 has been marked as a duplicate of this bug. ***
Comment 41 Matthias Versen [:Matti] 2008-09-19 18:22:13 PDT
*** Bug 401440 has been marked as a duplicate of this bug. ***
Comment 42 Matthias Versen [:Matti] 2008-09-19 18:22:35 PDT
*** Bug 306473 has been marked as a duplicate of this bug. ***
Comment 43 Damon Sicore (:damons) 2008-09-24 10:42:29 PDT
Late in the game, but getting this on the radar for 1.9.1.
Comment 44 Matthias Versen [:Matti] 2008-09-29 06:56:26 PDT
*** Bug 457673 has been marked as a duplicate of this bug. ***
Comment 45 Emile 2008-11-13 03:11:45 PST
(In reply to comment #43)
> Late in the game, but getting this on the radar for 1.9.1.

Is there any guarantee this will be in the 1.9.1 release? And when would this release be due? your Schedule says mid Nov for beta2, when would the public release go out?
Comment 46 Masayuki Nakano [:masayuki] (Mozilla Japan) 2008-11-13 08:13:22 PST
This bug will not be fixed on 1.9.1. Because bug 272847 is not fixed yet. It changes some spec of windowless plugins. So, it should not be fixed after b2.
Comment 47 Zvi Schreiber 2008-11-13 08:58:55 PST
Help!  Seriously this bug effects millions of users on our site (http://G.ho.st) and many other major sites.  All our users outside the US cannot user their keyboards properly (so the Windows users switch to IE but the Mac and Linux users are completely stuck and cannot user our site).

Is there anything we can do to help get this fixed in 1.9.1?

By the way, why "windowless plugins" - isn't Flash a windowed plug-in?

Alternatively if we could change the spec for windowed plug-ins and have them participate in the z ordering (and why shouldn't they?) then we could have iframes in front of Flash without the need for wmode="transparent" and that would solve the problem for us and many other sites too.

Zvi
Comment 48 Simon Buckingham 2008-11-19 04:54:06 PST
The first post here is 2006 and still this bug has not been fixed. Disgusting!

Seen using Firefox 2.0.0.18, on Windows XP SP2, Flash version 9.0.115.0

Using an English keyboard, entering text in a Flash text field, where the Flash file is embedded with wmode=transparent, the @ symbol gives a ". This seems to work OK if the wmode=window (ie not transparent).

So this renders my e-mail entry text box as unuseable on Firefox currently.

Cheers Simon Buckingham, Creative Director, Icecandy Entertainment
simon@icecandy.com
www.icecandy.com
Comment 49 Masayuki Nakano [:masayuki] (Mozilla Japan) 2008-12-15 22:47:06 PST
Bug 272847 was fixed on trunk. I think that this bug can be fixed by flash player side. But I cannot input ä, ö and ü from German keyboard layout even if I switch the system locale to German. (Of course, I used the test version which given by Jeff.)

Jeff, do we need to wait the release of Unicode version of flash player?
Comment 50 Craig 2008-12-15 22:50:00 PST
Is it possible for this fix to make it into Firefox 3.1? I think I speak for us poor souls who must deal with Flash that this fix would be much appreciated as soon as possible. :-)
Comment 51 Masayuki Nakano [:masayuki] (Mozilla Japan) 2008-12-15 22:53:25 PST
(In reply to comment #50)
> Is it possible for this fix to make it into Firefox 3.1?

I'm not sure. It depends on the release driver team's decision.
Comment 52 Emile 2008-12-16 02:31:36 PST
(In reply to comment #50)
> Is it possible for this fix to make it into Firefox 3.1? I think I speak for us
> poor souls who must deal with Flash that this fix would be much appreciated as
> soon as possible. :-)

I Concur, I've already explained to Nike the issue and have highlighted this thread as a possible fix to the issues we've encountered. I can't wait to let them know you've fixed it, and finally update our designs to no longer use split input fields for email addresses.
Comment 53 Jeff Mott 2008-12-16 10:41:27 PST
>> Jeff, do we need to wait the release of Unicode version of flash player?

Yes, that should be available in the next major player release, but I can't comment on exactly when that might happen.
Comment 54 Sarah Allen 2008-12-16 11:59:42 PST
Jeff -- I remember Flash supporting unicode as far back as Flash Player 6.  What does Flash need to support to resolve this isse?
Comment 55 Zvi Schreiber 2008-12-16 12:09:14 PST
This works fine on IE - I don't think it's to do with unicode in Flash
Comment 56 Jeff Mott 2008-12-16 14:16:45 PST
Flash supports Unicode data, it has never supported Unicode keyboard input.  We get our keyboard input from the OS / host app in code page and convert it to Unicode.  This causes all sorts of messy problems.  The next version of the player should support real Unicode keyboard input.

Zvi, the reason it works in IE is that in IE we get WM_CHAR events in windowless mode.  In Firefox we don't - until Masayuki lands his patch.  However, when that patch lands the WM_CHAR events we're going to get will be Unicode events, so we'll have to change the player (which we're already working on for all targets) to deal with Unicode WM_CHAR events.
Comment 57 astgtciv 2008-12-16 14:51:21 PST
I hope that as a result of this fix the same thing won't happen as is happening in IE/wmode=transparent - which is that (at least) each of the cyrillic characters entered get broken from a single 4-byte character into 2 2-byte characters, resulting in garbage being displayed.
Comment 58 Sarah Allen 2009-01-05 11:03:25 PST
Note: this bug has been confirmed fix at Laszlo for our use case: entering german '@' sign with wmode='opaque' (which had the same behavior as transparent)

Took a little while to be sure.  We have a feature that is enabled when the user agent contains "Firefox" which had to be hacked to make it work with Minefield that does not contain "Firefox" in the user agent string.  Is that on purpose?
Comment 59 Martijn Wargers [:mwargers] (not working for Mozilla) 2009-01-05 11:08:10 PST
Yes, it is on purpose that Minefield is called Minefield. It means that it is an experimental build.
Web developers shouldn't do UA detection to make scripts work, in general.
Comment 60 Matthias Versen [:Matti] 2009-01-05 11:31:35 PST
using Firefox in an UA detection string is wrong in every case, use Gecko instead : http://www.geckoisgecko.info/
Comment 61 Fred 2009-02-05 04:16:31 PST
Anyone in this mailing list able to summarise the status of this bug? Thanks.

I have checked out FF 3.1 Beta2, and it seems that the bug still there.

Just simply not able to enter @, €, etc..using German keyboard, when wmode is transparent/opaque.
Comment 62 Jeff Mott 2009-02-05 09:18:19 PST
You won't see this bug fixed until you have new releaes of both Firefox and Flash Player.  I don't know which Firefox release the fix will be in, and I can't comment on exactly when the Flash Player will be released.
Comment 63 Sean Owhady 2009-02-05 09:50:44 PST
Jeff, this is pretty unacceptable, there have been plenty of Firefox and Flash Player releases since this problem was first reported in the middle of 2006.  I'm sure I speak for this whole group, and Flash developers everywhere, when I say we deserve SOME kind of estimate as to when this long overdue bug will be fixed.  This is preventing all non-us keyboards from inputting text into Flash for any layered implementation.  This precludes all kinds of commerce, interactivity, and web 2.0 promise, international audiences have been left 5 years behind the curve.

The cynical part of me can somewhat understand that Mozilla might not have that much interest in making the preeminent rich media application work properly under their browser for most of the world, but I'm deeply surprised that Adobe is letting this gross oversight go ignored for so so long.  That you are refusing to put any weight behind an initiative that is so vitally important.  Reading through Adobe documentation, one gets the feeling that you don't even understand the depth of the issue, that you think this is a annoyance regarding a few special characters and not something that renders double-byte input useless.  

This is a formula for self-inflicted obsolescence.
Comment 64 paddy 2009-02-05 10:32:47 PST
Sean, you do speak for the whole group! this bug seems to be in a no-mans land between Adobe and Mozilla. After 3 years and however many flash/firefox releases, it would be great to be told how far along Adobe/Mozilla are in fixing this issue.
Comment 65 Jeff Mott 2009-02-05 10:39:24 PST
We're almost there.  Masayuki has written the patch, it's up to Mozilla when it lands.  I've been working on the player code for months, so that it can be in the next major release.
Comment 66 paddy 2009-02-05 10:53:31 PST
Thanks Jeff,
That does sound very promising ;)
Comment 67 Zvi Schreiber 2009-02-05 11:02:00 PST
Well, #63 was a little harsh (for all of that FF is a great product and it's
free) but yes, many people have been waiting for this for a long time.

Here's another point - for us and maybe for most sites the main issue requiring
wmode=transparent/opaque is that we want to show iframes in front of the flash
programs.  Now it turns on that for FF on Linux/Mac you can show an iframe in
front of a Flash without using wmode=transparent at all (as you can on IE,
Chrome and Safari).  

So for us even better than fixing this issue would be changing FF on Windows to
behave like FF on Linux and other browsers and allow iframes to be layered in
front of Flash movies.

In the meantime by the way we have implemented a workaround to pass in the keystrokes from Javascript onkeypressed event - that works for European languages but not for the text input programs used with Asian languages.
Comment 68 Masayuki Nakano [:masayuki] (Mozilla Japan) 2009-02-05 12:25:06 PST
(In reply to comment #62)
> I don't know which Firefox release the fix will be in,

1.9.1b3 and later for flash player.
# For other plug-ins, I need to remove the limitation on trunk.
Comment 69 Fred 2009-02-05 19:54:54 PST
Hi All,

Thanks for the update.

In reply to comment #67)
> wmode=transparent/opaque is that we want to show iframes in front of the flash
> programs.  Now it turns on that for FF on Linux/Mac you can show an iframe in
> front of a Flash without using wmode=transparent at all (as you can on IE,
> Chrome and Safari).  
> 
Hi Zvi,

Yes, we have the same issue, when using the iFrame feature. However, it seems to  happen for ALL browsers here. If wmode=tranparent is not set, (using wmode=window. The iFrame wouldn't be able to display on top of the Flash. Is there other alternative, to workaround the iFrame issue, so that ONLY FF cannot work?
Comment 70 Zvi Schreiber 2009-02-05 21:21:52 PST
I think we put launch the iframe from another div or something and it displays fine in front of the Flash an in all browsers except FF/Windows and Safari.  As I said it works fine in FF on Linux/Mac which is why I hope they could fix FF/Windows to behave the same
Comment 71 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-02-06 03:12:58 PST
(In reply to comment #68)
> (In reply to comment #62)
> > I don't know which Firefox release the fix will be in,
> 
> 1.9.1b3 and later for flash player.
> # For other plug-ins, I need to remove the limitation on trunk.

FYI, that means the fix has been checked in and will be part of Firefox 3.1, which will be released quite soon.
Comment 72 gerd.flender 2009-02-17 02:50:20 PST
With the actual nightly I have now the problem that the special keys TAB and BACKSPACE no longer work in the flash application.
TAB leads away from the flash application to the browser URL window and BACKSPACE goes back on page in the browser (like you hit the back button).

You can verify that at the above mentioned page:
http://g.ho.st/vc.html
With former versions that worked fine.
Comment 73 Masayuki Nakano [:masayuki] (Mozilla Japan) 2009-02-17 03:28:20 PST
Please file a bug for new regression.
Comment 74 Gilles Vandenoostende 2009-02-20 02:35:54 PST
Just a quick comment to say that it STILL hasn't been fixed. 

I've complained to adobe and they say it's firefox, and reading this site you guys are blaming flash for it. 

Just get it sorted out please. There's no reason html content shouldn't be visible above flash content without wmode opaque/transparent.
Comment 75 Matthias Versen [:Matti] 2009-02-20 08:37:00 PST
Gilles Vandenoostende:
>Just a quick comment to say that it STILL hasn't been fixed.
In which build did you test it and with which flash player ?
Your whole comment is useless without reading the whole bug and adding version numbers in your comment.
Comment 76 msa.tgix 2009-03-11 09:06:12 PDT
Works with Minefield 3.2a1pre and Flash Player 10.0.22.87, SWF in opaque mode and Swedish keyboard. However, the first key entered using AltGr (for example the @-sign) misses the first time; I load the page, click the TextArea and type AltGr+2 and the first time I get the character "2" (AltGr not detected). Second time and so on it works fine.
Comment 77 msa.tgix 2009-03-16 06:54:57 PDT
FireFox 3.1 beta 3 (Windows XP / Player 10.0.22.87) allows input of affected characters BUT misses the first character as MineField does, see comment #76.
Comment 78 Marty Pitt 2009-07-23 08:49:25 PDT
Hi

I'm on FF 3.0.12 and FP 10.0.22.87 still has this problem.   Is this fixed?  If so, in which FF version?

REgards

Marty
Comment 79 Jeff Mott 2009-07-23 09:38:45 PDT
FF 3.1, FP 10.1
Comment 80 Jonathon Green 2009-12-01 06:52:30 PST
Running FF 3.5.5, FP 10.1 Prerelease.
WMode Opaque.

Thus far the fix seems to be working, although the first character inputted will default to that of the US standard keyboard layout every successive keypress seems to produce the expected result. Can anyone else confirm this is a 99.999% fix?

Thanks, Jeff Mott and Masayuki Nakano.
Comment 81 Nicolas Schudel 2009-12-17 10:09:35 PST
Looks like the problem is fixed in Firefox 3.5.6 and Flash Player MAC 10,0,42,34. Thank you!
Comment 82 Nicolas Schudel 2009-12-17 10:38:49 PST
(In reply to comment #81)
> Looks like the problem is fixed in Firefox 3.5.6 and Flash Player MAC
> 10,0,42,34. Thank you!

My bad, I mean Flash Player WIN 10,0,42,34 (on Windows XP)
Comment 83 ZigDaPig 2010-09-22 12:28:21 PDT
The problem of the key mappings with wmode=transparent
were indeed fixed in Firefox 3.5.6, but the problems are back as of 3.6.3 (verified on 3.6.10 as well).

This was verified with flash player WIN 10,1,82,76
and a Belgian keyboard.

Typing the @ character (= Alt-Gr + 2) in a flash inputfield does NOT work
when wmode is set to transparent.

It seems kinda sloppy that this bug was re-introduced because I'm 100% sure it was gone with Firefox 3.5
Comment 84 ZigDaPig 2010-09-22 14:24:47 PDT
Would it be possible to update the status of this bug to "critical" ?

Using something other than wmode=transparent is not an option for my website,
so I currently have found no other option than to add a warning to users of the website, indicating that FireFox contains a bug.

You can test the behaviour at www.energiedesk.com/Offerte.html
Comment 85 Jean-Yves Perrier [:teoli] 2010-09-23 00:40:03 PDT
This is working on your site for me with a swiss-french keyboard, 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b7pre) Gecko/20100922 Firefox/4.0b7pre 

and the latest Flash (10.1.85.3).

You should go to a support forum as your problem is likely local to your computer.
Comment 86 ZigDaPig 2010-09-27 03:08:56 PDT
Teoli2003, this problem is NOT local to my computer and has been verified
on different computers.

But you appearantly tested this with FireFox 4.0 beta release, while
I clearly indicated that the problem occurs with the current production release.
(Firefox 3.6.10)

Anyway, your post indicates that the next production release (4.0) should fix this bug again, which is what I hoped for.
Comment 87 Jean-Yves Perrier [:teoli] 2010-09-27 03:32:19 PDT
ZigDaPig, you should try in Fx 4.0beta, then with the latest Flash Player. You're the only reporting this in Fx 3.6 for the moment, so maybe the condition to trigger the bug are more complex than the steps you gave in comment 83.
Comment 88 lime 2010-09-27 03:52:08 PDT
No, I can confirm the bug is still present on Firefox 3.6.10 on Windows XP and latest flash player using italian keyboard.
Comment 89 ZigDaPig 2010-09-27 04:43:21 PDT
This bug is triggered for all keyboards where you need to type a combination of 
<Alt-Gr> + <another key> to get a certain symbol.

So it appears to be linked to the Alt-Gr key.

e.g. The same problem occurs with a US keyboard where the €-sign is under
Alt-Gr + 5
Comment 90 Christoph Petersen 2010-09-27 04:45:22 PDT
Also true for German keyboards. Alt-Gr + E or Alt-Gr + Q doesn't print anything.
Comment 91 Matthias Versen [:Matti] 2011-03-20 09:21:45 PDT
*** Bug 643276 has been marked as a duplicate of this bug. ***
Comment 92 JayB 2011-03-24 08:34:52 PDT
This bug is back in FF4. It was gone in FF 3.6

Tested on Win XP and Win 7: A flash object in wmode opaque or transparent will not accept any character that needs the AltGr key. As international keyboards generate the @ sign with AltGr, input of Email addresses in flash objects with transparent/opaque won't work. That makes many websites useless...

Thanks for taking a look.
Comment 93 meunier.fabien 2011-04-03 18:40:18 PDT
Agree with last comment. You can test this bug with FF4 on the flash application embed in this page http://nicolas.cynober.fr/blog/116,flex-workaround-for-wmode-bug.html
Comment 94 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-04-07 14:58:08 PDT
Josh, is there a new keyboard input spec for windowless plugins or is that Mac only?
Comment 95 Michael Placke 2011-04-15 02:21:32 PDT
It's worse this time. With Versions before 3.6.5 I had the chance to use a workaround for the key mapping. Now even the wrong keys won't find their way into the flash container.

I hope this time we won't have to wait 4 years for a fix of the problem.
Comment 96 Jeff Mott 2011-04-15 07:40:11 PDT
To my kknowledge, nothing has changed on the Flash Player side. If there is anything I can do to help get this resolved please let me know.
Comment 97 Jeff Mott 2011-04-15 08:15:42 PDT
I just tried debugging the latest player against the latest released version of FF4.  Using a Russian keyboard and the sample app here http://baseonmars.co.uk/bugs/wmode, when I press the 'a' key in the top box (window mode) I get a WM_CHAR event with a uParam of 1092, which the player renders as 'ф'. When I press the 'a' key in the second box (opaque mode) I get a WM_CHAR event with a uParam of 97, which renders as 'a' of course.

Hope that's helpful.
Comment 98 Jeff Mott 2011-04-15 08:59:35 PDT
Sigh.  User error.  Keyboard choice didin't follow from one window to the next. Russian works fine in all cases. I do see the issue with AltGr on German keyboard - AltGr+e in windowless produces no input. In window mode, I get a WM_CHAR with uParam=8364 and render €. In opaque or windowless mode, I don't get a WM_CHAR.
Comment 99 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-17 20:00:27 PDT
Hmm, nsWindow still dispatches the native events by plugin event (not keypress event when AltGr is pressed). However, nsObjectFrame::HandleEvent() doesn't catch the event.
Comment 100 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-17 20:12:46 PDT
Looks like most event handling code doesn't assume the plugin events as input events. That causes the difference between keypress event handling and plugin event handling. I'll try to write the fix.
Comment 101 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-18 01:20:17 PDT
Created attachment 526674 [details] [diff] [review]
Patch v1.0

The plugin event is handled by chrome always. We should redirect it to (last) focused DOM window in the window.

# the only caller of NS_IsEventTargetedAtFocusedWindow() is PresShell::HandleEvent().
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#6279
Comment 102 Olli Pettay [:smaug] 2011-04-18 09:16:42 PDT
Comment on attachment 526674 [details] [diff] [review]
Patch v1.0

r+, but I hope jimm or someone else familiar with 
Windows widget level code reviews this too.
Comment 103 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-18 15:54:32 PDT
Comment on attachment 526674 [details] [diff] [review]
Patch v1.0

(In reply to comment #102)
> Comment on attachment 526674 [details] [diff] [review]
> Patch v1.0
> 
> r+, but I hope jimm or someone else familiar with 
> Windows widget level code reviews this too.

Hmm, this isn't a bug of Window's widget code, this might be regressed by widget removal or something. Maybe, roc is better widget reviewer?
Comment 104 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-04-18 16:12:37 PDT
Comment on attachment 526674 [details] [diff] [review]
Patch v1.0

I think NS_IS_PLUGIN_EVENT, NS_PLUGIN_EVENT, and nsWindow::DispatchPluginEvent should all be renamed to something like PLUGIN_INPUT_EVENT and DispatchPluginInputEvent. This redirection only makes sense for input events.

Also, we should have a testcase using the test plugin so this doesn't regress again!
Comment 105 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-18 18:55:07 PDT
(In reply to comment #104)
> Comment on attachment 526674 [details] [diff] [review]
> Patch v1.0
> 
> I think NS_IS_PLUGIN_EVENT, NS_PLUGIN_EVENT, and nsWindow::DispatchPluginEvent
> should all be renamed to something like PLUGIN_INPUT_EVENT and
> DispatchPluginInputEvent. This redirection only makes sense for input events.

Okay, I'll post the renaming patch on another bug. This patch is very simple, so, I think we can get approval for branches easier than the renamed patch.

> Also, we should have a testcase using the test plugin so this doesn't regress
> again!

I tried to think about the tests for this. But I've not found the smart way. Should I add sendPluginInputEvent() to nsIDOMWindowUtils and test only the communication of the event between widget and nsObjectFrame? I have no idea to test the nsWindow for Windows because it looks the native message queue.
Comment 106 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-04-18 19:15:43 PDT
How about using nsIDOMWindowUtils::sendNativeKeyEvent to try to send key events to the plugin?
Comment 107 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-18 19:25:45 PDT
nsWindow::SynthesizeNativeKeyEvent() doesn't use the message queue of Windows. And RemoveMessageAndDispatchPluginEvent() is never called then.
http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindow.cpp#6989

So, I have no idea of the way to kick RemoveMessageAndDispatchPluginEvent() from script.
Comment 108 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-04-18 19:44:55 PDT
Maybe extend nsWindow::SynthesizeNativeKeyEvent so that if PluginHasFocus, we call DispatchPluginEvent?
Comment 109 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-19 23:01:50 PDT
Created attachment 527199 [details] [diff] [review]
Tests v1.0

How about this test?

I realize that I forgot to remove the plugin name check in SendNativeEvents(). That was added for risk management for final release. We should remove it for other plugins such as Silverlight.
Comment 110 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-04-20 16:29:21 PDT
Comment on attachment 527199 [details] [diff] [review]
Tests v1.0

+every keydown event handling.

"every keydown event."
Comment 111 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-20 16:47:26 PDT
Created attachment 527423 [details] [diff] [review]
Patch v1.0 (mq)
Comment 112 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-20 16:48:01 PDT
Created attachment 527424 [details] [diff] [review]
Tests v1.0 (mq)
Comment 113 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-20 17:06:20 PDT
http://hg.mozilla.org/mozilla-central/rev/dcc0cb62ed0d
http://hg.mozilla.org/mozilla-central/rev/0c3bd5909e79

I'll request the approval for aurora and 4.0 branch.
Comment 114 Nicolas Lann 2011-04-22 00:53:31 PDT
Just to let you know that a similar issue was in Chrome and Adobe has done a fix in the latest 10.3.181:
"I'm the Flash Player dev at Adobe who works on this. Testing with latest Chrome 10.0.648.205 and latest internal player build for player 10.3, WM_CHAR issues are fixed.  Russian / Greek input works, AltGR works"
i checked and it seems to work now on Chrome but not in Firefox 4.
Comment 115 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-22 01:50:05 PDT
Nicolas:

This bug is Gecko's bug, not Flash Player's. Fx4 doesn't send WM_CHAR message to Flash Player if it's windowless and AltGr is pressed.
Comment 116 Elia Morling 2011-04-27 23:43:23 PDT
My goodness gracious. This is not fixed in 2006??
Comment 117 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-04-28 21:50:38 PDT
Comment on attachment 527423 [details] [diff] [review]
Patch v1.0 (mq)

We should fix this on branches.

This bug had been reported in 2006. The original reported problem was fixed by bug 272847 (on Fx3.6). But unfortunately, the fix is needed the update of Flash Player too. Therefore, this bug wasn't marked as FIXED at that time. And I forgot to close this bug after Flash Player was updated.

When we shipped Fx4.0, this bug was back but it affects only to AltGr and IME. Probably, widget removal or something is the cause of this. On Fx3.6, we don't need to redirect the plugin input event to focused presShell, however, on Fx4.0 and later, we need to do so.

This patch adds the plugin's input event to the list of "events are needed to be redirected to the focused presShell". And the plugin's input event is only used on Windows and it's only dispatched to windowless Flash Player. Not used for other contents. Therefore, the risk is low but the regression is very serious for some users who use AltGr or IME on Flash Player.
Comment 118 Benjamin Smedberg [:bsmedberg] 2011-05-04 11:54:02 PDT
Comment on attachment 527423 [details] [diff] [review]
Patch v1.0 (mq)

I think this can wait 6 weeks without harming anyone really seriously.
Comment 119 pott 2011-05-16 05:17:35 PDT
sorry but this affects all sites in full flash in France
Comment 120 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-05-16 17:59:29 PDT
(In reply to comment #119)
> sorry but this affects all sites in full flash in France

No, this bug is only for windowless Flash Player.
Comment 121 Nicolas Lann 2011-05-17 00:44:40 PDT
Thanks(In reply to comment #120)
> (In reply to comment #119)
> > sorry but this affects all sites in full flash in France
> 
> No, this bug is only for windowless Flash Player.

But windowless flash are very important :) With flash in window mode, we cannot change the z-order (so it's a nightmare to add HTML/flash above the flash) and indeeed cannot play with transparency.

Someone knows in which future version of Firefox it will be fixed ?
Firefox 4.1 ? Firefox 5 ?

Thanks
Comment 122 Masayuki Nakano [:masayuki] (Mozilla Japan) 2011-05-17 01:37:54 PDT
> Someone knows in which future version of Firefox it will be fixed ?
> Firefox 4.1 ? Firefox 5 ?

Firefox 6 which is going to ship in this autumn.
Comment 123 Patrick Tai 2011-05-17 01:47:02 PDT
A previous comment from Benjamin S on the 2011-05-04 was mentionning 6 weeks ? How hard would it be to add the fix in the next FF update ?
Comment 124 Nicolas Lann 2011-05-17 03:50:55 PDT
Yes, I'm a bit disappointed that it is not included at least in firefox 5. 

You may think this bug is not critical but some sites are now broken, like for instance "store.nike.com", where it is not possible de go to the payment step without the ability to enter '@' character which is necessary for emails. 

Of course as a developer I can overcome the bug for my sites by removing wmode transparent, but as a visitor, I see a lot of flash based sites that may or may not be fixed, and are broken right now.
Comment 125 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-05-17 04:13:26 PDT
Comment on attachment 527423 [details] [diff] [review]
Patch v1.0 (mq)

Maybe release-drivers should reevaluate based on above information.

Note that this has been on trunk for a month and no regressions have been reported.
Comment 126 IcePanther 2011-05-17 05:45:39 PDT
I agree with Nicolas Lann and others.

Many sites including commercial sites can suffer from this, especially in europe where Firefox's market share is high (see here, among other references http://uk.reuters.com/article/2011/01/04/us-internet-europe-idUKTRE70324F20110104) so that's almost 2 on 5 customers that may just think the site is broken and go elsewhere.
Comment 127 Patrick Tai 2011-05-17 05:55:11 PDT
A Swiss bank has their users unable to log or even register on one of their websites because of this bug. Go and tell their users that you have to copy and paste your email because the @ cannot be entered under Firefox, so embarrassing. Yes please review your release plan for this fix.
Comment 128 Asa Dotzler [:asa] 2011-05-18 23:38:44 PDT
Comment on attachment 527423 [details] [diff] [review]
Patch v1.0 (mq)

Nominating for beta because this is a regression that broke a number of topiste registration and payment systems for large numbers of European users.  The patch has been on m-c for almost one month with no fall-out. I really think we should take this.
Comment 129 Asa Dotzler [:asa] 2011-05-19 15:13:47 PDT
Comment on attachment 527423 [details] [diff] [review]
Patch v1.0 (mq)

Please land this change on both Aurora and Beta. (In the future, getting changes in during Aurora will save you this extra step.)
Comment 130 Nicolas Lann 2011-05-25 00:43:52 PDT
Does this mean that the bug will be sure fixed in firefox 5 ?
Or there is still some process needed to have the fix accepted in this version ?
I tried both Aurora and Beta channels and the bug was still there on both.

Thanks.
Comment 131 Nicolas Lann 2011-05-30 06:58:46 PDT
I checked again today and it seems to be fixed in the latest Aurora release. 
Thanks
Comment 132 Asa Dotzler [:asa] 2011-05-31 12:40:54 PDT
I see it made the migration from m-c to 6 Aurora but I don't see this in 5 Beta.
Comment 133 Matthias Versen [:Matti] 2011-05-31 15:11:20 PDT
*** Bug 660772 has been marked as a duplicate of this bug. ***
Comment 134 Christoph Petersen 2011-06-27 00:24:52 PDT
*** Bug 586939 has been marked as a duplicate of this bug. ***
Comment 135 christian 2011-07-13 13:54:14 PDT
I checked and these are on beta as well, marking as fixed.

Note You need to log in before you can comment on or make changes to this bug.