Closed Bug 497900 Opened 15 years ago Closed 4 years ago

Flash keyboard navigation erratic/inconsistent

Categories

(Firefox :: Keyboard Navigation, defect)

Product:
Firefox
Component:
Keyboard Navigation
Version:
3.5 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
status1.9.1 --- wanted

People

(Reporter: zforray, Unassigned)

References

(
URL
)

Details

(Keywords: flashplayer, regression)

Attachments

(1 file)

Files to reproduce the problem
9.21 KB, application/zip
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99 (.NET CLR 3.5.30729) www.crickler.com uses Flash for an online crossword puzzle. In 3.5, when using the keyboard to navigate from one user input area another, the cursor will jump multiple rows/move erratically. In 3.0.x, IE, Chrome, keyboard movement is as it should be, one space or row at a time. Reproducible: Always Steps to Reproduce: 1. Start a puzzle at www.crickler.com 2. Use cursor/arrow keys to navigate up/down 3. Watch cursor jump multiple rows Actual Results: Cursor jumps multiple rows/moves erratically. Expected Results: Cursor should move 1-row up/down.
Keywords: flashplayer
Version: unspecified → 3.5 Branch
We've also experianced this same bug in 3.5.1 and today updated to 3.5.2 and this bug is still very much present. Adobe also have this on their tracker here - http://bugs.adobe.com/jira/browse/FP-2432 There is a workaround, (remove wmode) however this isn't really a "fix".
Seems to be a firefox issue. The last two version of Flash Player work on earlier version of Firefox.
Same thing here (3.5.2 windows xp). KEY_DOWN event dispatched twice when pressing arrow keys with wmode="opaque". Everything is fine on Mac.
I just tried to look at this again and I am unable to see this with the suggested web site. Can anyone else confirm?
I'm attaching a zip with a HTM, SWF and FLA source to reproduce the problem. Unzip to a folder and open the HTM file. Click to focus on flash and start pressing arrow keys. You should be able to see twice keyCodes (37, 38, 39, 40) pressing once. The problem is reproducible only on windows boxes, FF 3.5+
Okay got it. Thanks
Blocks: 512532
What is the error condition with the attached test case? 1 keycode or 2?
the error is that two are produced when only one is expected.
Craig, thanks. I couldn't reproduce on Minefield (trunk) going back to Jan 2009. I'm bandwidth limited at the moment, if someone could download nightly builds of 3.5 and find a regression range that would be really cool. Otherwise, I'll do it in the morning (2am-7am et) when my bandwidth is unmetered.
Ok. Confirmed on 1.9.1 from today but not 1.9.2/1.9.3.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Tracking with #2434234
Keywords: regression
Flags: wanted-firefox3.6?
Flags: blocking-firefox3.6?
regression range is 2008-12-29 (pass) 2008-12-30 (fail) http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2008-12-29&enddate=2008-12-31 the checkin masayuki@d-toybox.com Tue Dec 30 06:17:20 2008 -0800 looks about right, especially the http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a939730d65c4 Bug 272847 Text input via IME does not work in windowless Flash movie
Hrm, it's strange, I cannot reproduce this on trunk but I can reproduce on 1.9.1 branch...
I cannot reproduce this bug on 1.9.2 branch too. This bug is only on the 1.9.1 branch.
blocking2.0: --- → ?
Flags: wanted-firefox3.6?
Flags: blocking-firefox3.6?
(In reply to comment #14) > I cannot reproduce this bug on 1.9.2 branch too. This bug is only on the 1.9.1 > branch. Ah, I cannot reproduce this bug on the 1.9.1's debug build too. What's happened??
I confirmed that I cannot this bug on Fx3.6's nightly build. If you can reproduce this on Fx3.6 branch, please re-nominate to the blocking 3.6.
(In reply to comment #16) > I confirmed that I cannot this bug on Fx3.6's nightly build. I meant, I cannot reproduce this bug on... sorry for the spam.
Jeff, does the flash player change the behavior from the name of the host browser? E.g., Firefox vs. Minefield.
I could not reproduce this on 1.9.2 or 1.9.3 using the appropriate nightly builds, so I don't think this is related to application name. I think this is (for some reason only) on 1.9.1 windows. Removed 1.9.3 blocking request and set 1.9.1 blocking request.
blocking1.9.1: --- → ?
blocking2.0: ? → ---
We don't have any code checking for Minefield. Some places in the player we have to distinguish between Firefox / Opera / Etc. Other places we go further and deal with browser versions to work around issues. Can't be sure off hand if such tweaks are involved here, I'll have to do some debugging on Monday. Where should I get a Firefox / Minefield build that shows this issue?
(In reply to comment #19) > Removed 1.9.3 blocking request and set > 1.9.1 blocking request. Oops, sorry, thanks. (In reply to comment #20) > Where should I get a Firefox / Minefield build that shows this issue? I confirmed this bug on the Fx3.5.3. http://www.mozilla.com/en-US/ Here is a Shiretoko build (Shiretoko is the code name of Fx3.5). http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/ This is the latest build of the Fx3.5.x (of course, this is test build, not released build). I tested on the latest 1.9.1 (Shiretoko) build too. Then, I can reproduce this bug on it too. So, my guess (the application name is related) should be wrong. I cannot understand what is the cause...
And you can get the Minefield which is trunk build (will be Fx3.7) from here. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
I also build an official build of 1.9.1 branch, but I cannot reproduce this bug on the debug build. I guess that the cause might be a build option...
I've just downloaded from the nightly and tested here and I can confirm that we can not produce this bug in that version - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090917 Minefield/3.7a1pre (.NET CLR 3.5.30729) I've tested with the sample files provided and with our application that was suffering from this problem and both work normally...
Was this an introduction then to 3.5? I didn't do any regression testing but this is sounding more like a mozilla bug?
Charles this is a Firefox 3.5.x Windows only bug. It does not appear to be a problem in the Flash player.
With the 1.9.1.4 codefreeze in 4 days this can't realistically "block" the release. As a regression we should fix it, but on the other hand it's good that Firefox 3.6 won't have the problem.
Assignee: nobody → masayuki
Blocks: 272847
blocking1.9.1: ? → ---
status1.9.1: --- → wanted
Um, I couldn't reproduce on my builds (with some build options, e.g., --enable-official-branding, --enable-jemalloc). I have no idea for debugging this...
Assignee: masayuki → nobody
Ok, the most recent comment on the Adobe ticket: http://bugs.adobe.com/jira/browse/FP-2432 Tested with latest flash player and various versions of firefox and we believe this to be a Mozilla bug. Versions previous to 3.5 are not showing this behavior. Beuller... Anyone?
This only occurs when wmode is set to opaque. I have created a simple test flex app that shows this bug. Here is the page without using wmode which works correctly: http://74.213.164.31/test/flex_firefox_bug/no_wmode.html Here is the same exact flex app with the only change to the HTML to use wmode to opaque: http://74.213.164.31/test/flex_firefox_bug/wmode_opaque.html The HTML I used to embed the flash is the one that's auto-generated by Flex Builder. As you can see, with wmode set to opaque, using the arrow keys results in moving the cursor 2 characters in the text input, and also jumping 2 lines in the list. This problem is only in Firefox 3.5

https://www.adobe.com/products/flashplayer/end-of-life.html

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: