92060 - onKeyPress should not fire when tab-navigating a form

Status: RESOLVED DUPLICATE of bug 968056

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

Description

[Skewer]

Procedure: Use onKeyPress on a text object to capture the entry of text.
Tab-navigate this form.

Expected: The tab key it is not expected to fire the onKeyPress event. Tab is
equivalent to mouse-clicking the next form object, and should only fire onBlur.
In cases where JavaScript is used to prevent the entry of text, this could cause
accessibility problems.

Actual: Tab key fires onKeyPress.
Build: 2001072303 Win98

Comment 1

[Phil Schwartau]

Browser, not engine ---> Event Handling component.

[e-mail] : is there a URL or a reduced testcase for
this bug? You can attach a reduced testcase via the link 
"Create a new attachment" above.

That will speed things along; thanks - 

Comment 2

[Brian Nesse (gone)]

cc'ing accessibility folks for input as to whether they feel this might be an
accessibility issue and important in the 1.0 timeframe.

Comment 3

[Harry Loots]

This is an accessibility bug - in order to comply with accessibility guidelines,
onkeypress is used alongside onclick (i.e.: to aid users who do not have the use
of a mouse or other pointing device). 
Once the user has tabbed to an anchor that contains the an onkeypress event
handlers they are stuck. Nothing except picking up the mouse allows one to
navigate away from the anchor. They can not tab to a next link; nor use alt <-
to go back to previous page. alt-F4 closes the window, but only after is has
fired the event (note: this is not fired on alt, but on the F4 key, suggesting
that the alt key does not fire script event handlers; and that it may be easy to
simply add the tab key to this configuration?
If you need an example web site to test this, please let me know.

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

Always provide examples if you have them.  It helps us out.

But I have to ask, why can't the event handler just run a check to see if the
key pressed was a tab key?

Comment 5

[Aaron Leventhal]

Yes, please provide a sample web page.

Comment 6

[Pham]

.

Comment 7

[Vedran Miletic]

retargeting

Comment 8

[louis bennett]

-> all/all because this happens in mac os x, too, and adding relevant keywords.

adding URL for the UAAG that we're violating.

i'll attach a test case in a moment.

Comment 9

[louis bennett]

Attachment: test case

Comment 10

[Vlad Alexander]

We are a WYSIWYG tool vendor and our application adds the following markup to the <a> element when the user specifies that they want a link to open in a new window:

onclick="window.open(this.href);return false;" onkeypress="window.open(this.href);return false;"

When visitors to the site tab through the page content, onkeypress fires and FF tries to open a new window. Tabbing through page content should not fire the onkeypress event.

You can find a test case on the home page here:
http://xstandard.com

Comment 11

[Marco Zehe (:MarcoZ)]

(In reply to comment #10)
> We are a WYSIWYG tool vendor and our application adds the following markup to
> the <a> element when the user specifies that they want a link to open in a new
> window:
> 
> onclick="window.open(this.href);return false;"
> onkeypress="window.open(this.href);return false;"

Vlad, onkeypress is overkill for this purpose. onclick already takes care of the keyboard equivalent of pressing Enter on the link element. Only if you had an ondblclick handler, that would need a keyboard equivalent in onkeypress. onclick is handled automatically.

Comment 12

[Mike Taylor [:miketaylr]]

This is fixed (in Nightly) by 968056, but I'm going to dupe it because we can't quite ship just yet. See 968056 for more details.