Key events are not cancellable

VERIFIED WONTFIX

Status

()

Core
Event Handling
P2
normal
VERIFIED WONTFIX
20 years ago
14 years ago

People

(Reporter: joki (gone), Assigned: joki (gone))

Tracking

({helpwanted, qawanted, regression})

Trunk
Future
helpwanted, qawanted, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm-] relnote-devel, URL)

(Assignee)

Description

20 years ago
Currently key events are not cancellable.  Returning false still allows
character entry into edit fields.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 1

20 years ago
Setting all current Open/Normal to M4.

Comment 2

20 years ago
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Updated

20 years ago
QA Contact: 4015 → 3847

Comment 3

20 years ago
QA contact re-assigned according to the product areas we're currently working
on.
(Assignee)

Updated

20 years ago
Target Milestone: M4 → M5
(Assignee)

Comment 4

20 years ago
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.
(Assignee)

Comment 5

19 years ago
Not making these for M5
(Assignee)

Updated

19 years ago
Target Milestone: M6 → M7
(Assignee)

Comment 6

19 years ago
Still not fixed but not critical for M6.
(Assignee)

Comment 7

19 years ago
*** Bug 2083 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

19 years ago
Target Milestone: M7 → M8
(Assignee)

Comment 8

19 years ago
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.
(Assignee)

Updated

19 years ago
Target Milestone: M8 → M9
(Assignee)

Comment 9

19 years ago
This has actually been fixed and broken a few times.  I'm moving it and keeping
it open for now.
(Assignee)

Updated

19 years ago
Target Milestone: M9 → M10
(Assignee)

Comment 10

19 years ago
We just agreed to more changes in keyhandling which won't all be in till after
M9.  Moving again.  Sigh.

Comment 11

19 years ago
Joki thinks this might just work (it's so crazy...) with gfx text widgets.
Buster, can you tell?

/be

Updated

19 years ago
Whiteboard: [help wanted] needs a test case. come on, all you javascript jockeys!

Comment 12

19 years ago
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.

Updated

19 years ago
Target Milestone: M10 → M11

Comment 13

19 years ago
Jan, can you create a test case for this.  Moving to M11.

Is the GFX text control turned on yet?

Updated

19 years ago
Target Milestone: M11 → M10

Comment 14

19 years ago
Actually, will keep on M10 whilst don and team investigates.

Comment 15

19 years ago
Moving to M11.  Not to hold for M10 per conversation with joki during bug triage
today.

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 16

19 years ago
I'm pretty sure that this is fixed now since xul keybinding is definitely
consuming/cancelling events now.

Marking fixed.

Updated

19 years ago
Keywords: verifyme

Comment 17

18 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer

Comment 18

18 years ago
Updating QA Contact.
QA Contact: ckritzer → lorca

Comment 19

18 years ago
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.
Status: RESOLVED → REOPENED
Keywords: verifyme → regression, relnote3, relnoteRTM
OS: Windows NT → All
Resolution: FIXED → ---
Target Milestone: M11 → ---

Comment 20

18 years ago
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

Comment 21

18 years ago
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...

Comment 22

18 years ago
It'd be nice.
Keywords: 4xp, rtm

Comment 23

18 years ago
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)

Comment 24

18 years ago
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>

Comment 25

18 years ago
*** Bug 28323 has been marked as a duplicate of this bug. ***

Comment 26

18 years ago
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

Comment 27

18 years ago
Test case from duplicate bug:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=5394
*** Bug 64825 has been marked as a duplicate of this bug. ***

Comment 29

18 years ago
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.
(Assignee)

Comment 30

18 years ago
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.
(Assignee)

Comment 31

18 years ago
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
Last Resolved: 19 years ago18 years ago
Resolution: --- → WONTFIX

Comment 32

18 years ago
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

Comment 34

17 years ago
QA contact updated
QA Contact: gerardok → madhur

Comment 35

17 years ago
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?

Updated

17 years ago
Status: RESOLVED → VERIFIED

Comment 36

17 years ago
verifying

Comment 37

15 years ago
*** Bug 228850 has been marked as a duplicate of this bug. ***

Comment 38

14 years ago
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.
You need to log in before you can comment on or make changes to this bug.