dave Reporter
	Description • 16 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

When typing in an Adobe Flash file, hitting the = key will actually type +. I believe this is due to an incorrect character keystroke mapping that is sent to flash. Equals signs show up properly in flash. You can copy and paste other equals signs, but you cannot type a new one as it will just be typed as a plus sign.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.millerhighlife.com
2. Complete age verification
3. On the main page, click "Browse" where it says "Miller High Life Extras". (this is located underneath the headline and right below the main navigation)
4. Type = into the Email Address Field in the site that pops up (in a popup)
5. Note that it will type +
Actual Results:  
You cannot type an equals sign; it will always render as a plus sign.

Expected Results:  
Adobe Flash should have the correct keystroke mappings and you should be able to type an equals sign.

This was tested on several computers with Firefox 3 and was reproducible every time.

	Mark Sinagra
	Comment 1 • 16 years ago

same problem on the site http://www.stickam.com . it only occurs when you open a chat in a separate window though.

	Lorien Henry-Wilkins
	Comment 2 • 16 years ago

This problem occurs when the wmode on the swf is not set to "window". I've attached two sample pages that embed a very simple flash movie that just has a text input. In wmode-window.html the wmode is set to "window" and you'll see that you can type "=" as expected. In wmode-opaque.html you'll see that when you attempt to type "=" you get "+" instead. This is an issue that was introduced in firefox 3. In firefox 2 using the same version of flash this problem does not exist. This problem is occurring in flash player 9.0.124, and seems to only be a problem on windows. Mac with Firefox 3 works fine.

	Damon Sicore (:damons)
	Comment 3 • 16 years ago

Adding to the 1.9.1 queue.

	Jeff Mott
	Comment 4 • 16 years ago

There has always been some bugginess with key codes in windowless mode.  Here's a summary:

FF2 behavior:

Semicolon/colon (aka VK_OEM_1). Passed as 59, should be 186.
Equals/plus (aka VK_OEM_PLUS). Passed as 61, should be 187.
Dash/underscore (aka VK_OEM_MINUS). Passed as 109, should be 189.


FF3 behavior:

Semicolon/colon (aka VK_OEM_1). Passed as 59, should be 186.
Equals/plus (aka VK_OEM_PLUS). Passed as 107, should be 187.
Dash/underscore (aka VK_OEM_MINUS). Passed as 109, should be 189.


We were able to code around the FF2 behavior, at the expense of forcing the keypad minus key to behave as if it were the keyboard dash/underscore key.  Because both keys send us a 109 we can't distinguish between them.  This at least mostly works:  When keypad minus is hit we generate a '-' character.  But when it is hit in combination with the shift key we generate '_', which is a bit odd, and there's no way to register a keyboard event listener for keypad minus in ActionScript because it never occurs.

We have no way to code around the new equals/plus behavior in FF3.  Because keypad plus and keyboard equals/plus are both sending us a code of 107, if we treat them identically then the keypad plus key will generate "=" when hit normally, and '+' only when hit in combination with the shift key which clearly won't fly.

Hopefully there's a quick fix for this - we'd just like Firefox to send us the same events, whether its windowless or not.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 5 • 16 years ago

o.k. taking.

However, unfortunately, we cannot fix this bug without the patch of bug 272847. Because nsWindow doesn't know whether the focused element is plugin or not.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 6 • 16 years ago

(In reply to comment #4)
> FF3 behavior:
> 
> Semicolon/colon (aka VK_OEM_1). Passed as 59, should be 186.
> Equals/plus (aka VK_OEM_PLUS). Passed as 107, should be 187.
> Dash/underscore (aka VK_OEM_MINUS). Passed as 109, should be 189.

Fx trunk should send the correct keycode which is after "should be". So, flash player can fix this bug.

	Sarah Allen
	Comment 7 • 16 years ago

I tried this with 
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.2a1pre.en-US.win32.installer.exe	16-Dec-2008 05:46 	7.3M

and it was fixed!  yay!

	Jeff Mott
	Comment 8 • 16 years ago

I don't think this will require any changes on the player side.

	Sarah Allen
	Comment 9 • 16 years ago

I may have spoken too soon... I'm not seeing the html iframe layer over the Flash app in Minefield, so I'm not sure the javascript is doing the same thing. I'll investigate further.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 10 • 16 years ago

(In reply to comment #8)
> I don't think this will require any changes on the player side.

Ah, right. I confirmed this bug is fixed on English locale Windows.

-> FIXED

	Sarah Allen
	Comment 11 • 16 years ago

Note: this is confirmed fixed by Laszlo in Minefield.

	Brendan Eich [:brendan]
	Comment 12 • 16 years ago

Competitive issue given OpenLaszlo generating code for all browsers.

/be

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 13 • 16 years ago

We haven't traced any regressions due to this fix. I say we take it on 1.9.1.

	Benjamin Smedberg
	Comment 14 • 16 years ago

Bug 272847 is fixed1.9.1

	Aakash Desai [:aakashd]
	Comment 15 • 15 years ago

verified FIXED on builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090406 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090406045355

and

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090331 Shiretoko/3.5b4pre (.NET CLR 3.5.30729) ID:20090331041754