Closed Bug 1572 Opened 26 years ago Closed 24 years ago

Key events are not cancellable

Categories

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

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

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: joki, Assigned: joki)

References

(
URL
)

Details

(Keywords: helpwanted, qawanted, regression, Whiteboard: [rtm-] relnote-devel)

Currently key events are not cancellable. Returning false still allows character entry into edit fields.
Status: NEW → ASSIGNED
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
QA Contact: 4015 → 3847
QA contact re-assigned according to the product areas we're currently working on.
Target Milestone: M4 → M5
This should pretty much go away once bug 3546 is fixed. But since it is different I'll keep it open. Either way, however, its not a big deal, moving to M5 to await testing.
Not making these for M5
Target Milestone: M6 → M7
Still not fixed but not critical for M6.
*** Bug 2083 has been marked as a duplicate of this bug. ***
Target Milestone: M7 → M8
Lots of changes in key handling recently. Not going to rock the boat with this as any critical key stuff is being handled elsewhere. I'll fix in M8 after the dust settles.
Target Milestone: M8 → M9
This has actually been fixed and broken a few times. I'm moving it and keeping it open for now.
Target Milestone: M9 → M10
We just agreed to more changes in keyhandling which won't all be in till after M9. Moving again. Sigh.
Joki thinks this might just work (it's so crazy...) with gfx text widgets. Buster, can you tell? /be
Whiteboard: [help wanted] needs a test case. come on, all you javascript jockeys!
There's a good chance this will work correctly with gfx text controls. The editor is just processing dom events. Key input occurs on keyPress. If the javascript does a cancel on a keyDown, that should surpress the associated keyPress, right? I don't know what a cancel on keyPress means, probably just that keyUp never gets fired. Anyway, if I can get a testcase and it does not work, there's probably a few minutes of work I need to do to propogate the "cancelled" state of the event back into the embedded webshell that holds the editor in a text control.
Target Milestone: M10 → M11
Jan, can you create a test case for this. Moving to M11. Is the GFX text control turned on yet?
Target Milestone: M11 → M10
Actually, will keep on M10 whilst don and team investigates.
Moving to M11. Not to hold for M10 per conversation with joki during bug triage today.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I'm pretty sure that this is fixed now since xul keybinding is definitely consuming/cancelling events now. Marking fixed.
Keywords: verifyme
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
This bug is not fixed. Reopen, there's a nice simple testcase from the netscape documentation [url]. The event does trigger, but it doesn't cancel. not onkeypress nor onkeydown.
URL: http://developer.netscape.com/docs/ma...
Status: RESOLVED → REOPENED
Keywords: verifyme → regression, relnote3, relnoteRTM
OS: Windows NT → All
Resolution: FIXED → ---
Target Milestone: M11 → ---
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Keywords: helpwanted, qawanted
Whiteboard: [help wanted] needs a test case. come on, all you javascript jockeys! → Want help: need a test case. come on, all you javascript jockeys!
Target Milestone: --- → Future
I take it there is no interest in nominating this for RTM? Going through my bugs that are P1 or P2...sorry for the spam...
It'd be nice.
Keywords: 4xp, rtm
Adding testcase from bug #28323, which seems to be a duplicate. http://bugzilla.mozilla.org/showattachment.cgi?attach_id=5394 Comments from testcase maker: (martin.honnen@t-online.de) bug demo (first field should cancel any key, second any numerical)
Source for said testcase, just in case (pun intended). <HTML> <HEAD> <STYLE> </STYLE> <SCRIPT> function validateNonNumber (evt) { var keyCode = evt.which ? evt.which : evt.keyCode; return keyCode < '0'.charCodeAt() || keyCode > '9'.charCodeAt(); } </SCRIPT> </HEAD> <BODY> <FORM NAME="aForm"> <INPUT TYPE="text" NAME="field" ONKEYDOWN="return false" > <BR> <INPUT TYPE="text" NAME="aField" ONKEYDOWN="return validateNonNumber(event)" > </FORM> </BODY> </HTML>
*** Bug 28323 has been marked as a duplicate of this bug. ***
Not a stop ship bug. We'll get to this post Netscape 6.0. Marking rtm-
Whiteboard: Want help: need a test case. come on, all you javascript jockeys! → [rtm-]
Keywords: relnote3
Whiteboard: [rtm-] → [rtm-] relnote-devel
*** Bug 64825 has been marked as a duplicate of this bug. ***
From bug 64825- Kevin Jacobs noted: One difference between [bug 64825] and [this bug]: Keys are correctly canceled for OnKeyPress, but not for OnKeyDown. ---------- If this beef is not appropriate for this bug, please reopen the other.
The comment above is correct. When these key event were ungergoing standardization a decision was made that keypress event would be cancelable but keydown, keyup events would not. The same functionality previously available via cancellation of keydown events still works but only via cancellation of keypress.
I'm going to go ahead and mark this WONTFIX. 6.0 simply handles these cases differently in what was supposed to be a standard way. You can easily use KeyPress instead and get the same affect. We designed as we did due to the standards process at the time and making this work would be very difficult.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WONTFIX
Key events in prelim DOM3 docs sofar are all 3 cancellable.
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
Joki, any comment on the current DOM3 events spec? http://www.w3.org/TR/2001/WD-DOM-Level-3-Events-20010410/events.html#Level-3-Events-KeyEvents-Interfaces Is an HTML DOM3 Events update on it's way or did the wg decide otherwise?
Status: RESOLVED → VERIFIED
verifying
*** Bug 228850 has been marked as a duplicate of this bug. ***
The referenced DOM spec clearly lists both keydown and keyup events as cancelable. And keypress is not equivalent, as asserted above, since it does not deliver non-character keystrokes like the arrow keys and escape. As such, I think this bug warrants further attention and should be reopened.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.