Closed Bug 111335 Opened 23 years ago Closed 21 years ago

{pp}Onkeydown event not working on anchor element

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
PowerPC
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.4final

People

(Reporter: chrispetersen, Assigned: saari)

References

(
URL
)

Details

(Keywords: crash, regression) 

Build: 2001112004

Platform : All

Expected Results: Onmousedown event should be processed and a alert dialog
should  open.

What I got: Nothing happens.

Steps to reproduce:

1) Open test case 

http://mozilla.org/quality/browser/standards/html/a_onkeydown.html

2) Place focus on link

3) Press a key down on keyboard.

4) No alert dialog is open.
Severity: normal → major
Keywords: regression
Whiteboard: pdt2
Changing summary
Summary: Onmousedown event not working on anchor element → Onkeydown event not working on anchor element
Removing PDT2.
Whiteboard: pdt2
This wfm on win2k buildID: 2001-11-21-10trunk
but I do see the problem on macOS9.1 buildID: 2001-11-21-12trunk build.
onKeydown event does not bring the popup alert box on the mac platform.
This works for me on Win2K as well.  Based on info below changing platform to
Mac.  Passing to saari in hopes that he may find time to take a look.
Assignee: joki → saari
Hardware: All → Macintosh
Tested on 12_04_10_trunk build. WORKSFORME
This isn't happening on the Windows build. It's a Mac only issue. Still occurs
in the Mac OS X Dec 6 th build (2001-12-06-08).
Summary: Onkeydown event not working on anchor element → {pp}Onkeydown event not working on anchor element
I think it's not just anchor elements; form text fields too. See
http://www.capital.net/~dittmer/mozilla_bug_onkeydown.html for an example.
Typing text into the field should trigger an alert box, but nothing happens.
onKeyUp and onChange seem to work fine.
This problem is affecting several of my test, any progress on this issue ?

Related to http://bugzilla.mozilla.org/show_bug.cgi?id=122479
Accesskey is not functional with A, Button, Textarea or Label elements
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Adding nsbeta1
Keywords: nsbeta1
ADT need info: How are typical users affected by this?  Any scenarios on top 500
sites?
Whiteboard: ADT need info
Need to research that specific issue. But this problem is not restricted to just
onkeydown.. Accesskey functionality is simply not working,  look at Comment 10#.
All of tests pass in NS 6.2.1 (0S X, OS 9) and our supported in IE 5.1.3 (OS X).
nsbeta1- per ADT triage team, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
I realize I'm the only one who voted for this bug, but it's nonetheless
disappointing to see it bumped to 1.2, especially given the lengthened milestone
cycle in 2002; I was hoping for 1.1 at the latest.
Knowing nothing about the source code, am I naive to assume that if onKeyUp
triggers correctly, onKeyDown can't be that hard to fix?
This bug may not affect any top 500 sites (which probably use few onKey triggers
to begin with), but it's important for delivering functional web apps. Please
reconsider the 1.2 classification.
pulling into 1.0 to keep on my radar and incase I have time
Target Milestone: mozilla1.2 → mozilla1.0
QA Contact: madhur → rakeshmishra
OnKeydown functionality is not working on button,textarea, radio,
checkbox,submit,reset for the Mac OSX and Mac OS9 for the build
2002-05-12-17-7.0PR1.
Remove minus from nsbeta1. This is a problem on the mac only that needs to be
resolved. This is working in NS 6.2.3.
Keywords: nsbeta1- → nsbeta1
using build 20022023 on Mac OS X, browser crashes. adding KW:crash
Keywords: crash
Priority: -- → P2
under Mac OS X with Mozilla 1.2 alpha (build 2002091014), the onkeydown event 
is never fired. 
because the keypress-event does not have any information about the keyCode, it 
is noct possible to cancel any key (i.e. esc or Apple-R for Reload) with Mac 
OS. Cancelling a key at onKeyUp does not cancel the key.

when will this bug be fixed? it seriously harms the delivery of our commercial 
web application that we currently port from IE to mozilla (about 20000 users 
in Germany!).
Any relation to bug 44259 or bug 148130? Does this block bug 122479?
This is unrelated to bug 44259 since that bug is specific to certain shifted
keyUp and keyDown events.  This bug can be seen by pressing any letter.

Did this break when we switched over to IME events?  We should be synthesizing
the events but maybe we aren't anymore?
QA Contact: rakeshmishra → trix
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Whiteboard: ADT need info
Depends on: 184549
resolving as fixed with patch from bug 184549
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0 → mozilla1.4final
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.