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.