Closed Bug 347185 Opened 18 years ago Closed 13 years ago

when using wmode="transparent" for flash movie, german keyboard produces english characters

Categories

(Core Graveyard :: Plug-ins, defect, P1)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows XP
Type:
defect

Tracking

(firefox6 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla6
Tracking Flags:
Tracking Status
firefox6 --- fixed

People

(Reporter: m, Assigned: masayuki)

References

(
URL
)

Details

(Keywords: intl)

Attachments

(4 files, 2 obsolete files)

Matrix of Browser/Flash/OS versions for reproducibility of bug
358 bytes, text/plain
Details
AS2 Fix class
2.53 KB, application/octet-stream
Details
Patch v1.0 (mq)
700 bytes, patch
asa
: approval-mozilla-beta+
christian
: approval2.0-
Details | Diff | Splinter Review
Tests v1.0 (mq)
10.15 KB, patch
Details | Diff | Splinter Review 
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.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: unspecified → 1.8 Branch
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.
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.

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
I confirm

In FF 1.5.0.10 is the same thing
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 1.8 Branch → Trunk
Flags: blocking1.9?
-'ing since it is not a regression.  Nice to have a fix if someone should produce one.
Flags: blocking1.9? → blocking1.9-
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?
Flags: blocking1.9- → blocking1.9?
Priority: -- → P3
(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

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. 


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.

+'ing with P2.  Johnny, can you take a look at this?
Flags: blocking1.9? → blocking1.9+
Priority: P3 → P2
Is there any progress or prospect of progress on this bug?  Flash Player would dearly love to see this working.  Thanks!
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.
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.
Would love to see this fixed in FF3.
This has been around for such a long time.
Come on - do it!
Cheers
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.)
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
Zvi: That is why this bug is marked as NEW. We know it is not fixed yet.
Flags: wanted-next+
Flags: tracking1.9+
Flags: blocking1.9-
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. 
A matrix of information on browser/flash/os version combinations and the reproducibility of this bug.
Can do nothing ?
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!
Fix this huge bug !!!!
i wonder if i should say please ?.... after 2 years ...
this is a major bug for everyone.
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.

:)

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!

:)
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.
Attached file AS2 Fix class — 
A fix that temporarily fixes this BUG (IN AS2!!!)
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!
(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.
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.
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. 
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.


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!
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 
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.
Late in the game, but getting this on the radar for 1.9.1.
Flags: wanted1.9.1+
Priority: P2 → P1
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Depends on: 272847
Keywords: intl
(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?
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.
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
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
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?
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. :-)
(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.
(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.
>> 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.
Jeff -- I remember Flash supporting unicode as far back as Flash Player 6.  What does Flash need to support to resolve this isse?
This works fine on IE - I don't think it's to do with unicode in Flash
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.
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.
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?
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.
using Firefox in an UA detection string is wrong in every case, use Gecko instead : http://www.geckoisgecko.info/
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.
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.
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.
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.
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.
Thanks Jeff,
That does sound very promising ;)
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.
(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.
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?
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
(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.
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.
Please file a bug for new regression.
Blocks: 478862
No longer blocks: 478862
Depends on: 478862
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.
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.
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.
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.
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
FF 3.1, FP 10.1
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.
Looks like the problem is fixed in Firefox 3.5.6 and Flash Player MAC 10,0,42,34. Thank you!
(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)
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
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
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.
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.
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.
No, I can confirm the bug is still present on Firefox 3.6.10 on Windows XP and latest flash player using italian keyboard.
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
Also true for German keyboards. Alt-Gr + E or Alt-Gr + Q doesn't print anything.
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.
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
Josh, is there a new keyboard input spec for windowless plugins or is that Mac only?
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.
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.
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.
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.
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.
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.
Attached patch Patch v1.0 (obsolete) — — Splinter Review 
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
Attachment #526674 - Flags: review?(Olli.Pettay)
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.
Attachment #526674 - Flags: review?(Olli.Pettay) → review+
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?
Attachment #526674 - Flags: review?(roc)
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!
Attachment #526674 - Flags: review?(roc) → review+
(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.
How about using nsIDOMWindowUtils::sendNativeKeyEvent to try to send key events to the plugin?
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.
Maybe extend nsWindow::SynthesizeNativeKeyEvent so that if PluginHasFocus, we call DispatchPluginEvent?
Attached patch Tests v1.0 (obsolete) — — Splinter Review 
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.
Attachment #527199 - Flags: review?(roc)
Comment on attachment 527199 [details] [diff] [review]
Tests v1.0

+every keydown event handling.

"every keydown event."
Attachment #527199 - Flags: review?(roc) → review+
Attached patch Patch v1.0 (mq) — — Splinter Review 

        Attachment #526674 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Tests v1.0 (mq)
        — 
          — Splinter Review
      

    


  

        Attachment #527199 -
        Attachment is obsolete: true

    
    

    
  
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.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
My goodness gracious. This is not fixed in 2006??

    
    

    
  
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.

        Attachment #527423 -
        Flags: approval2.0?

        Attachment #527423 -
        Flags: approval-mozilla-aurora?

    
    

    
  
Comment on attachment 527423 [details] [diff] [review]
Patch v1.0 (mq)

I think this can wait 6 weeks without harming anyone really seriously.

        Attachment #527423 -
        Flags: approval-mozilla-aurora? → approval-mozilla-aurora-

    
  

        Attachment #527423 -
        Flags: approval2.0? → approval2.0-

    
    

    
  
sorry but this affects all sites in full flash in France

    
    

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

    
    

    
  
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

    
    

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

    
    

    
  
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 ?

    
    

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

        Attachment #527423 -
        Flags: approval-mozilla-aurora- → approval-mozilla-aurora?

    
    

    
  
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.

    
    

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

        Attachment #527423 -
        Flags: approval-mozilla-aurora? → approval-mozilla-beta?

    
  

        Attachment #527423 -
        Flags: approval-mozilla-beta? → approval-mozilla-beta+

    
    

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

        Attachment #527423 -
        Flags: approval-mozilla-aurora+

    
    

    
  
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.

    
    

    
  
I checked again today and it seems to be fixed in the latest Aurora release. 
Thanks

    
    

    
  
I see it made the migration from m-c to 6 Aurora but I don't see this in 5 Beta.

    
  

        Attachment #527423 -
        Flags: approval-mozilla-aurora+

    
    

    
  
I checked and these are on beta as well, marking as fixed.

          status-firefox6:
          --- → fixed

    
  
Product: Core → Core Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: