Closed
Bug 92060
Opened 24 years ago
Closed 6 years ago
onKeyPress should not fire when tab-navigating a form
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
DUPLICATE
of bug 968056
Future
People
(Reporter: SkewerMZ, Assigned: MatsPalmgren_bugz)
References
()
Details
(Keywords: access, polish)
Attachments
(1 file)
(deleted),
text/html
|
Details |
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•24 years ago
|
||
Browser, not engine ---> Event Handling component.
SkewerMZ@skewer100.cjb.net : 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 -
Assignee: rogerl → joki
Component: Javascript Engine → Event Handling
QA Contact: pschwartau → madhur
Updated•23 years ago
|
Target Milestone: --- → mozilla1.1
Comment 2•23 years ago
|
||
cc'ing accessibility folks for input as to whether they feel this might be an
accessibility issue and important in the 1.0 timeframe.
Updated•23 years ago
|
QA Contact: madhur → rakeshmishra
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Comment 3•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
Yes, please provide a sample web page.
Comment 8•21 years ago
|
||
-> 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.
OS: Windows 98 → All
Hardware: PC → All
Comment 9•21 years ago
|
||
Updated•19 years ago
|
Assignee: saari → mats.palmgren
Comment 10•17 years ago
|
||
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•17 years ago
|
||
(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.
Updated•15 years ago
|
QA Contact: ian → events
Comment 12•6 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•