in flashplayer, when the html object and embed tag has wmode="transparent", it is impossible in Firefox to type an @ or . because the keyboard does not work properly (alt gr and shift are disabled)




13 years ago
13 years ago


(Reporter: bart, Assigned: Blake Ross)


Firefox Tracking Flags

(Not tracked)





13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; nl-NL; rv:1.7.6) Gecko/20050226 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl-NL; rv:1.7.6) Gecko/20050226 Firefox/1.0.1

wmode=transparent makes the flashmovie behave transparent. When trying to fill
in a form to enter my email, I had to fill in the @. It was impossible to do so
because not all keys work properly.
Copying the '@' solved the problem, but this is not supposed to be a solution.
Even a '.' is impossible to type with an azerty-keyboard, since you would have
to use the shift-key (which also doesn't work). 
A blinking cursor is also not shown...
Possibly a flash player problem?

Reproducible: Always

Steps to Reproduce:
1. make a flashfile with an insert field (include all signs, also the @)
2. set in html code the swf with wmode="transparent" (in embed and object tag)
3. use Firefox to surf to the page
4. fill in the emailaddress
5. you don't see a blinking cursor, nor it is possible to type an '@'

Actual Results:  
impossible to type '@'
keyboard does not function properly (FN, Shift, Alt, Alt-gr doesn't work)

Expected Results:  
Everything what it does normally (keys must work)

Comment 1

13 years ago
Any testcase?


13 years ago

Comment 2

13 years ago
(In reply to comment #1)
> Any testcase?

I added the url: => dutch site, but the emailform at
the bottom left is where you should look. Use firefox and try to fill in an @ or
any charcter that is formed by using special keys (such as ctrl, alt or alt gr
or even shift). Good luck ;)
Removing the wmode makes it possible to use your keyboard...

Comment 3

13 years ago
I have put up some more info on the subject and a minimal test case here:

Basically setting wmode to transparent or opaque breaks 1) the flashing cursors
one is supposed to see in textfields and 2) key mappings for non alpha-numeric
characters. It appears as though once wmode is set to transparent or opaque the
character set associated with the current keyboard is ignored and ASCII key
codes are used directly instead of contextually. For example, on a French
keyboard, typing Shift+2 will return the @ character instead of " as is usual on
French keyboards; but Shift+2 is the usual mapping for @ on English keyboards. 

John Dowell (one of the top guys at Macromedia) reports:


For what it’s worth, I’ve seen similar types of wacky things happen in some
browsers’ WMODE implementations in the past… there was one version of IE/Win
where using WMODE would result in upside-down printing, for instance.

(What’s “WMODE”? Usually the Macromedia Flash Player writes directly to the
screen — it completely owns a rectangle of pixels on the screen. Invoking the
WMODE attribute, in browsers which support it, routes that rectangle from the
Player to the browser, which can then composite it with its own elements,
enabling DIV overlays, non-rectangular (masked) displays, etc.)

Most of the squirrelly combos seem to be when the browser composites SWF content
which calls upon system-specific routines — in your case fontmapping, in the
above case printing — I don’t recall browsers mis-compositing this stuff when
it’s pure SWFfy stuff without system functions, but I don’t have a large enough
sample size to be sure.

Could I ask you to drop off the steps-to-repro at both the Macromedia and
Mozilla wishlist areas, please? I’m not sure if both engines could modify this,
or if the funny code is just in one browser, but it would be great to show both
development teams how to make it happen too. Thanks!"
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.