Closed Bug 478862 Opened 14 years ago Closed 14 years ago

After Bugfix 347185 the keys Backspace and Tab no longer work as expected in a flash application


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

Windows XP


(Not tracked)



(Reporter: gerd.flender, Assigned: masayuki)




(Keywords: flashplayer, regression, verified1.9.1)


(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b3pre) Gecko/20090216 Firefox/3.1b3pre

The fix for bug 347185 gives a new problem:

With the actual nightly ( from 2009-02-16) I have the problem that the special keys TAB and
BACKSPACE no longer work in a flash application as expected.

TAB leads away from the flash application to the browser URL window and
BACKSPACE goes back one page in the browser (like you hit the back button).

You can verify that at the above mentioned page:
With former versions that worked fine.

Reproducible: Always

Steps to Reproduce:
1. open the above mentioned URL
2. enter cursor in ID or password field
3. enter something
Actual Results:  
TAB leads away from the flash application to the browser URL window and
BACKSPACE goes back one page in the browser (like you hit the back button).

Expected Results:  
TAB should focus the next field in the flash application
BACKSPACE should only delete the last entered character

See also Bug 347185
Keywords: flashplayer
Version: unspecified → 3.1 Branch
Depends on: 347185
Blocks: 347185
Component: General → Plug-ins
No longer depends on: 347185
Product: Firefox → Core
QA Contact: general → plugins
Version: 3.1 Branch → Trunk
I'm not sure this is our bug. Because:
1. I cannot reproduce the backspace issue.
2. I cannot reproduce this bug on other site.
Hmm, maybe it's a problem with Openlaszlo.
It worked before the bugfix 347185.
Another requirement seems to be wmode="transparent" as it was for bug 347185

Do you see the tab problem on the above mentioned site?
The backspace issue occurs of course only if there is a page to which you can go back.
Attached patch Patch v1.0Splinter Review
ok, we should stop propagation of keypress events for compatibility.
Assignee: nobody → masayuki
Ever confirmed: true
Attachment #362748 - Flags: superreview?(roc)
Attachment #362748 - Flags: review?(roc)
We should fix this regression.
Blocks: 272847
Flags: blocking1.9.1?
Keywords: regression
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Plug-in may want to leave focus when TAB key is pressed (see bug 93149.)
Probably we will need a new NPAPI variable to determine whether we can trust a return value from NPP_HandleEvent().
I have seen in the past month or so in the branch nightlies, that the left and right arrow keys skip over 2 characters instead of one in some flash objects 

Also the home and end keys move to the top and bottom of the page, as well as the beginning and end of the line of text in the flash object.  When really the latter behavior should only be happening when the flash object has focus.
Kimura-san, you're right for the accessibility. But it should not be the scope of this bug and bug 272847. Because we should fix only "IME accessibility problem of windowless mode" and "some non-US keyboard layout accessibility problem of windowless mode".

And also we need to fix most regressions on the branch by low risk patch.
Attachment #362748 - Flags: superreview?(roc)
Attachment #362748 - Flags: superreview+
Attachment #362748 - Flags: review?(roc)
Attachment #362748 - Flags: review+
landed to trunk.

I'll land to 1.9.1 branch several days later.
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [c-n: baking for 1.9.1]
Target Milestone: --- → mozilla1.9.2a1
landed to 191branch too.
Keywords: fixed1.9.1
Whiteboard: [c-n: baking for 1.9.1]
Verified fixed with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090301 Shiretoko/3.1b3pre ID:20090301033810
Oh, could we somehow get this tested with the test plugin? Josh, would this be possible?
Flags: in-testsuite?
I'm not sure if it is possible to test, Masayuki would know. You'd probably have to generate a native key event from the test plugin, doesn't seem like it would be too hard.
How to write the plug-in tests? I don't know the "test plugin".
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.