335936 - Synthesized tab does not move focus

Status: UNCONFIRMED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Csaba Gabor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2

Synthesizing a tab press fails to move the focus, even when done in chrome.

If I have a textarea or button, focus will remain on the element, elem, if I do:
var ev = document.createEvent ('KeyEvents');
ev.initKeyEvent('keydown', true,true, window, false,false, false, false, 9, 0);
elem.dispatchEvent(ev);
ev.initKeyEvent('keypress', true,true, window, false,false, false, false, 9, 0);
elem.dispatchEvent(ev);

Reproducible: Always

Steps to Reproduce:
The attachment has instructions.  There are event handlers on the Test button and the textarea.  Clicking on the test button synthesizes a tab event, which is supposed to transfer focus to the textarea.  However, no focus change happens.

The event synthesis code is at the end of the file.

This is not a really fair test, however, because the attachment is not privileged.  However, the same code when privileged still fails to move the focus while allowing all other keystrokes I'm aware of.


Expected Results:  
I expect the focus to be moved to the next element in the focus chain.
This is the only keystroke sequence that I know of that is ignored from chrome.

Csaba Gabor from Vienna

I would like to emphasize that this happens from privileged code and it is the only keystroke so far whose effect I cannot duplicate.  I am writing an extension which may remap keys (user settable).  The tab key is stuck if it is not possible to synthesize tab key behaviour.


There is a second item that looks like a bug, which I'll file separately if I don't get any gainsaying comment about it: If you have caret browsing turned on, when you bring up the attachment and click the Test button, notice that the caret is above the Test button.  If you go to the textarea and enter text, clicking the Test button still shows this problem.  However, pressing the right arrow after clicking Test and then clicking Test again reverts the caret to expected behaviour.

Comment 1

[Csaba Gabor]

Attachment: Test button synthesizes Tab key

See initial bug report or attachment for instructions.

Comment 2

[Gary Bishop]

I see this same problem in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008060309 Firefox/3.0.

I'm working on an extension to enable switch access to FF. Most keys work but TAB is handled differently for synthesized key events than it is for events originating from the keyboard. I also see a related problem with Enter.

Comment 3

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090417 Minefield/3.6a1pre] (home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/b427fd627d36)

If the testcase is valid, then the bug is still there.