Last Comment Bug 167145 - cancelling keydown does not affect corresponding keypress/keyup
: cancelling keydown does not affect corresponding keypress/keyup
Status: RESOLVED FIXED
: access, dom0, dom1
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: P3 normal (vote)
: ---
Assigned To: Aaron Leventhal
: Vladimir Ermakov
Mentors:
http://jscript.dk/2002/9/ns7/keydown....
: 147865 174655 (view as bug list)
Depends on: 290131 291099 318525
Blocks: 317245
  Show dependency treegraph
 
Reported: 2002-09-06 12:17 PDT by Thor Larholm
Modified: 2014-01-16 08:38 PST (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Stopping the keydown propagation; preventing default action of keypress event. (6.69 KB, text/html)
2002-09-08 12:32 PDT, Gérard Talbot
no flags Details
rewrite test case to support nn4 (2.26 KB, text/html)
2002-09-09 17:43 PDT, Bob Clary [:bc:]
no flags Details
keypressdown.html - hacked example from msdn (928 bytes, text/html)
2004-12-07 14:16 PST, Bob Clary [:bc:]
no flags Details
Prevent default for onkeydown affects onkeypress and onkeyup (4.75 KB, patch)
2004-12-08 09:23 PST, Aaron Leventhal
no flags Details | Diff | Review
Testcase shows that onkeydown="return foo();" prevents keypress default action when false is returned, in both IE and Mozilla. Arrow keys in menu should change selected menu item, not scroll the page. (15.09 KB, patch)
2004-12-08 10:05 PST, Aaron Leventhal
no flags Details | Diff | Review
Testcase shows that onkeydown="return foo();" prevents keypress default action when false is returned, in both IE and Mozilla. Arrow keys in menu should change selected menu item, not scroll the page. (15.09 KB, text/html)
2004-12-08 10:05 PST, Aaron Leventhal
no flags Details
Prevent default for keydown affects keypress (4.63 KB, patch)
2004-12-08 11:36 PST, Aaron Leventhal
no flags Details | Diff | Review
improved keypressdown.html (964 bytes, text/html)
2004-12-08 15:32 PST, Bob Clary [:bc:]
no flags Details
Don't fire keypress if event status indicates no default (11.88 KB, patch)
2004-12-09 18:12 PST, Aaron Leventhal
no flags Details | Diff | Review
Make sure we handle WM_CHAR situation in Windows. Also fix another unhandled situation in gtk1 code. (13.33 KB, patch)
2004-12-10 06:51 PST, Aaron Leventhal
neil: superreview+
Details | Diff | Review
Same fix as before, but don't PreventDefault() in menubar's onkeydown listener, otherwise keypress doesn't happen. PreventBubble() and PreventDefault() are enough in that case. (14.97 KB, patch)
2004-12-20 08:06 PST, Aaron Leventhal
no flags Details | Diff | Review
Always fire keypress, but do PreventDefault() on it when that had happened on the corresponding keydown. Ignore prevent default flag in menu bar keypress listener. (25.96 KB, patch)
2004-12-21 05:42 PST, Aaron Leventhal
bryner: review+
neil: superreview+
Details | Diff | Review

Description Thor Larholm 2002-09-06 12:17:05 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0

The onkeydown event, possibly more or even all events, cannot be cancelled in
any way whatsoever. This applies regardless if one sets the event handler with
the DOM

element.addEventListener("keydown", testEvent, true);

or through quirks/property assignment

element.onkeydown = testEvent;

This bug breaks any event-driven DHTML anywhere that wants to cancel events.

Test examples are provided at

http://jscript.dk/2002/9/ns7/keydown.html (quirks)
http://jscript.dk/2002/9/ns7/keydownDOM.html (DOM)

This bug could be reproduced back to a build from 0427 (thank you, rginda).
This bug prevents me from properly using Mozilla for any input-driven DHTML.

Reproducible: Always

Steps to Reproduce:
1. Set the onkeydown event handler on any element
2. Try to cancel it
3. See it fail

Actual Results:  
Typing is possible, the onkeydown event is never cancelled. 

Expected Results:  
Typing should be impossible, since the onkeydown event should be cancelled.
Comment 1 Robert Ginda 2002-09-06 12:43:57 PDT
I've confirmed that the testcase fails to cancel keydown events on the 1.2trunk,
1.1 final, 1.0 final, and a random build from 0427. 
Comment 2 Randell Jesup [:jesup] 2002-09-06 13:03:55 PDT
This impacts dom0 and dom1 standards compatibility:
DOM0 (property assignment) and DOM1 (addEventListener)

Downgrading, this is not a blocker.  Adding jst
Comment 3 Vladimir Ermakov 2002-09-06 18:15:08 PDT
*** Bug 147865 has been marked as a duplicate of this bug. ***
Comment 4 Boris Zbarsky [:bz] 2002-09-07 01:17:06 PDT
Um.. you're cancelling the _keydown_ event.  But typing handles onkeypress. 
This question keeps coming up over and over: "should cancelling keydown cancel
the corresponding keypress as well?"
Comment 5 Boris Zbarsky [:bz] 2002-09-07 01:20:30 PDT
Also note that if I press and hold the "a" key there is one and only one keydown
event fired, followed by lots of keypress events (as the OS repeat setting kicks
in).  Should cancelling the one keydown cancel every single one of those
keypress events?

For that matter, should cancelling a mousedown cancel the click event that
corresponds to it?   That's the same situation...
Comment 6 Thor Larholm 2002-09-07 03:40:15 PDT
Yes, cancelling onkeydown should cancel the following (be it one or more) 
onkeypress events that trigger due to that onkeydown.

Whether Mozilla internally treats typing solely through keypress is irrelevant.

If nothing else, look at the current implementation in any other browser - 
cancelling onkeydown cancels typing.
Comment 7 Thor Larholm 2002-09-07 03:58:45 PDT
A reference test case to demonstrate how cancelling onkeydown also cancels 
onkeypress and prevents typing (in other browsers, and how it is supposed to 
be) can be found at

http://jscript.dk/2002/9/ns7/keydownReference.html

Please test the above page in Internet Explorer, then test the above page in 
Mozilla/NS7 - then compare the results.

Another bug seems to be demonstrated through the above test page. In 
Mozilla/NS7, you cannot read the keyCode inside a onkeypress event. Should I 
file this separately?
Comment 8 Boris Zbarsky [:bz] 2002-09-07 04:04:38 PDT
That's by design.  See the table in section 2 at
http://www.mozilla.org/editor/key-event-spec.html
Comment 9 Thor Larholm 2002-09-07 04:13:10 PDT
I take it that "That's by design" refers to keyCode returning 0 inside 
onkeypress.

Is it by design that A, B and C should return 0 inside onkeypress? This goes 
against any known implementation so far, onkeypress returns a keyCode in Other 
Browsers (tm). Unless some standard dictates that keyCode should be set to 0 
inside onkeypress, Mozilla should adopt the industry standard in use.
Comment 10 Boris Zbarsky [:bz] 2002-09-07 04:25:01 PDT
See also bug 112379.

Basically, that behavior is not likely to change unless there's an overwhelming
reason for it to change (and there's not, so far).  Changing it would be fairly
time-consuming and difficult...

As a note, it was implemented this way because the DOM Events spec drafts at the
time had it that way.  Key events were subsequently pulled from the spec
completely, but when they are reintroduced chances are this will be the way they
work.
Comment 11 Thor Larholm 2002-09-07 04:27:08 PDT
Is comment #10 about event.keyCode being 0 or about the original topic?
Comment 12 Boris Zbarsky [:bz] 2002-09-07 04:27:55 PDT
About event.keycode. Which we should take to that bug if we discuss it further.
Comment 13 Gérard Talbot 2002-09-08 12:23:22 PDT
I believe this bug is INVALID.

First of all, key events (including keydown) can stop their propagation and can
be prevented from doing their default actions. The following demo clearly
establishes that.

Second, as far as I can figure this out, (one of) the default action of keypress
is to visually render printable characters on the monitor video screen. I do not
see any default action for the keydown event, at least no clear one. So, if
that's true, then preventing the non-existent default action of keydown achieves
nothing; and if you believe that keydown is responsible for the display of
characters on the screen, then you'll be lead to believe there is a bug...

Third, from the beginning, it was assumed that the default action of keydown was
to display characters: it simply is not the case in Mozilla. Such assumption,
such cause-effect relationship has not been demonstrated nor documented in
demos, testcases, specifications, documentation, excerpts of source-code,
whatever...

Fourth: the word "cancel" is used a lot in this bug file. Nowhere do I read a
clear definition of what is canceling an event. All references around (MSDN,
Gecko DOM reference, online tutorials, columns, articles, books, etc.) will tell
you that you can prevent (or cancel) 2 aspects [1) propagation in the node
hierarchy and 2) default action] of an event but you just cannot "cancel" an
event: it's somewhat a misuse of words. Once an event is fired, it acts like an
object (because it is an object), just like a window, a document, etc... Now,
can you cancel a document? How do you cancel, say, a paragraph node? The closest
one can get to "canceling" an event would be to stop its propagation; preventing
its default action does not at all cancel an event.

Fifth: DOM level 3 makes a clear and distinct separation between keyCode and
charCode with new identifiers (keyVal <=> keyCode; outputString and
visibleOutputGenerated being a refinement and deconstruction of charCode
property I would say). Every key typed on a keyboard has a keyCode; not every
key typed on a keyboard corresponds to a printable character. Hence that's why
MSIE 5+ which supports only 1 property has chosen the keyCode property. If
keypress is the event responsible for displaying the typing, then it has to
return the charCode (the charCode property must correspond to a printable
character), not the keyCode.
http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/events.html#Events-UIEvent-keyVal

----------

Useful interactive demos on keydown/up/press:
http://www.din.or.jp/~hagi3/JavaScript/JSTips/Mozilla/Samples/KeyEvent.htm
http://www.xs4all.nl/~ppk/js/eventex.html 
Both pages are in backward compatible (Quirks) rendering mode.

---------------

Re: comment 5:
"(...)we have three to choose from. These include the two components of a
complete keypress: the key reaching the bottom of its physical travel (KeyDown),
and the instant at which the key starts its travel upward (KeyUp). The
combination of both actions constitutes a KeyPress event. This means we can, if
our application calls for it, assign a different script action to each event
during what a user would probably consider the single event of pressing a key.
If the user holds down a key, multiple KeyPress events occur, similar to the way
typed characters auto-repeat after a brief delay on most computers."
taken from
"THE JAVASCRIPT APOSTLE: GETTING READY FOR JAVASCRIPT 1.2 EVENTS"
found at:
http://developer.netscape.com/viewsource/goodman_events.html

-----------

A complex interactive testcase/demo is coming.
Comment 14 Gérard Talbot 2002-09-08 12:32:41 PDT
Created attachment 98335 [details]
Stopping the keydown propagation; preventing default action of keypress event.

This is a rather complex interactive demo. I think if you spend time on it (and
trying, playing with parts of the code also), you'll see that the keydown event
is "canceled" ... I mean here its propagation is stopped.

One important matter:
In the KeyPressManagement(evt) function, I wrote this:
/*
alert("evt.type = " + evt.type.toUpperCase() + "\nevt.currentTarget.nodeName =
" + (evt.currentTarget.nodeName ? evt.currentTarget.nodeName.toUpperCase() :
"WINDOW") + "\nevt.eventPhase = " + (evt.eventPhase == 1 ? "CAPTURE" :
evt.eventPhase == 2 ? "AT TARGET" : "BUBBLING"));
Uncommenting this alert will make the page jump. Nevertheless this alert is
very significant as it reveals 2 info:
1) evt.preventDefault() does NOT at all cancel an event as all its properties
are still available
2) when the event listener is set on the bubble phase for the window object,
then the keypress event reaches the window on its way up (the bubbling phase)
while the keydown event is still at the window object on its capture phase:
this proves furthermore the relative - if not total - independance of keypress
and keydown. In other words, the keypress event has finished his race while
keydown event is still at his first hurdle.
*/

So, I invite you to uncomment the alert and observe the behavior of the demo.
At first, the 2 alerts superpose each other; the first alert (keydown) is
masked by the 2nd alert (which is the keypress alert). The most interesting
matter is that the keypress alert can be triggered on its bubble phase for the
window (so that means at the absolute end of its "trip" within the containment
hierarchy while the keydown event is still at the window object in its capture
phase (so that means that the event is at the very beginning of its propagation
trip.). I think just this empirical discovery makes it clear that both events
(keydown and keypress) are pretty much distinct apart from each other.
Comment 15 Gérard Talbot 2002-09-08 12:42:15 PDT
Re: comment #4 and #5:

There is a difference between mousedown/click and keydown/press. If I mousedown
on a button but suddenly realize I'm making a mistake, I can then move my mouse
away from the button while maintaining the mouse down and by doing so, I will
not create a click event, only a mousedown event. This has happened to me quite
a few times.

But you cannot transpose this behavior to keydown and keypress. It appears that
if the key has been down over a certain period of time/delay in msec. (in
windows, this is settable) and if the keyboard "generates", "meets" a sufficient
keydown rate (also settable in windows), then a keypress will be triggered.

It appears impossible to physically "isolate" a keydown from a keypress; you can
physically "isolate" a mousedown from a click though.
Comment 16 Thor Larholm 2002-09-08 13:00:32 PDT
Comment # 13, 14 and 15:

Instead of being nitpicky about words (a whole section just to discuss the 
meaning of "cancel"?), why don't you try to be clear and simple instead of 
producing lengthy, complex demonstrations? Your comments seem lengthy and 
unnecessary, and more than anything they introduce a lot of misunderstandings 
and talk about how one should perceive the meaning of the words that has been 
put forth so far. More than anything, they add confusion and meaningless 
discussion to the bug report, without adding value and/or fixing anything.

In fact, that same thing goes for Boris, every comment since comment #4 has 
personally been a waste of time for me (though I did get to include a reference 
test, which I doubt you will try out for a lack of reference browsers) and I 
wonder why I should bother further.

Try to sumarize:
This breaks existiting functionality in most input-driven DHTML.
There is no publicly defined standard that dictates the behavior.
The implementation in Other Browsers(tm) clearly show that cancellling 
onkeydown prevents onkeypress.
In other words, cancelling onkeydown in Other Browsers(tm) prevents typing/the 
default action.
The current implementation in Mozilla/NS7 goes against any previously defined 
implementation, let's call that industry standards.
In lack of a public standard, how does Mozilla implement stuff? As the Other 
Browsers(tm) do, or as defined by industry standards.

I honestly fail to see the dilema here, and I fail to see what it is that you 
want to question about this bug - except for not doing as the Other Browsers
(tm) do.
Comment 17 Thor Larholm 2002-09-08 13:22:38 PDT
phew, good to get that out - no hard feelings, I hope ;)

Additional:
Mozilla should follow de-facto standard unless there are strong reasons not to 
(e.g., a public standard dictating otherwise).
DOM 1 and 2 says nothing about how a UA should handle this situation, and there 
might be no specifics about it in DOM 3 which would leave the interpretation to 
de-facto standards.
Comment 18 Boris Zbarsky [:bz] 2002-09-08 13:28:36 PDT
OK.  I agree that we should try to follow the de-facto standard here unless we
have _really_ strong reasons not to. Ray?  This is not going to be defined in
the DOM spec in the near future, right?  Doron?  Bob?  It seems that this would
make evangelism somewhat easier...
Comment 19 Gérard Talbot 2002-09-08 15:19:55 PDT
Thor, I put a lot of care, time and efforts into this demo and into explaining
it. I backed my claims with quotes, references, an empirical approach and links
to other demos. Your first comments in this bug file were certainly not precise
and quite categorical.

You didn't like the paragraph on the word cancel. For your information, this is
not nitpicking as you say: it has to do with understanding rather. What do you
exactly cancel when you "cancel" an event?

You first need to understand very well a problem before solving it and before
asking others to change a browser. If you rely too much on visual feedback, then
you will often be wrong on internet, in browser issues. Everyday in newsgroups
people shout about browser bugs when more than 3/4 of the time, the bugs are in
their own code.


>This breaks existiting functionality in most input-driven DHTML.
I never had any problem with NS 6+, Mozilla regarding filtering characters,
detecting keyboard typing, auto-tabbing, etc.. in all the pages I did. Can you
talk in the name of all others like you do? "This bug breaks any event-driven
DHTML anywhere that wants to cancel events."

>There is no publicly defined standard that dictates the behavior.
Ok, so, what's wrong with the current implementation? Show me where and how you
cannot detect (and prevent default action) a keystroke on the keyboard in any
Gecko-based browsers? If you're willing to claim that most DHTML web sites have
problem with this, you should be able to submit at least your page. Strange: I
can show you other sites explaining how they do it for Mozilla.

>The implementation in Other Browsers(tm) clearly show that cancellling 
onkeydown prevents onkeypress.
I don't need to have onkeydown to prevent/cancel/whatever onkeypress. Why do you?

>In other words, cancelling onkeydown in Other Browsers(tm) prevents typing/the 
default action.
I don't need to have the onkeydown to prevent typing/default action. Why are you
pressuring overworked Mozilla.org to do this? Instead of changing a browser,
maybe, just maybe, you could benefit from widening your knowledge. Does that
make sense?

>The current implementation in Mozilla/NS7 goes against any previously defined 
implementation, let's call that industry standards.
There is no industry standards. Not that I know of.
 
>In lack of a public standard, how does Mozilla implement stuff? As the Other 
Browsers(tm) do, or as defined by industry standards.
Mozilla.org implements stuff based on several criteria (severity, gravity,
dataloss,priority, objective constraints,etc..). Are you going to insist that
several people undo what has been done and spend time (how much?) just to
implement a different logic when the need is, to begin with, very relative,
quite debatable? I'm not talking about workaround here: how to filter
characters, detect characters is pretty much well known in DHTML-driven sites.

Who/what needs to improve here? Your pages, your coding techniques or the
Mozilla browser?

If you're going to be upset, make sure you are upset at the right person for the
good reason.
Comment 20 Thor Larholm 2002-09-09 00:40:25 PDT
Where is my ignore filter when I need it? ;)

drunclear@hotmail.com:
If compatibility with other browsers is irrelevant, why did Mozilla waste time 
on implementing HTML, CSS, DOM or any other standard? Why even care about DOM 0 
and quirks mode? Precisely, because compatibility, with standards and other 
browsers, matter.

Your claim that this bug is INVALID comes solely from the fact that the goal 
(preventing typing) can be accomplished in Mozilla, ignoring that Mozilla then 
have to be treated differently than any Other Browser(tm). You live in a 
fantasy world where 98% of the world does not exist, where nobody uses or code 
for IE.

I can understand that you spent a lot of time and effort on your demo and 
explanation. I can also understand that you are zealotting, and I can 
understand how I care not to waste more time on you.

Could we please go back to fixing this bug? WHOEVER@mozilla.org seem to agree, 
and have verified, that this is a bug. Now we just need to find a resolution.
Comment 21 Gérard Talbot 2002-09-09 03:23:00 PDT
> Your claim that this bug is INVALID 
Let me see. Did I claim that "Key events cannot be canceled" is invalid or did I
claim that "cancelling keydown does not affect corresponding keypress/keyup"? Or
was it that "keydown event cannot be canceled" rather? Or maybe was it that
"onkeydown event, possibly more or even all events, cannot be cancelled in
any way whatsoever."? Remember that you even had someone to back your claims on
top of all this.

Can the Mozilla browser "cancel" the keydown event? There has to be a yes or no
answer here: no "if... but", "maybe, but" here. Is there a bug related to the
propagation of the keydown event? There has to be a yes or no answer here. This
cannot be a vote issue (principle petition) or an opinion poll/survey. What do
you want others to fix exactly? Your pages or the browser? The question still
remains and, in a very time-constrained organization based on volunteer work,
such question is crucial. Does that perspective make sense?

"This bug breaks any event-driven DHTML anywhere that wants to cancel events."
"This bug prevents me from properly using Mozilla for any input-driven DHTML."
"Typing is possible, the onkeydown event is never cancelled."
"Typing should be impossible, since the onkeydown event should be cancelled."
All of the above is INVALID. And you can bring the whole Mozilla organization to
back you up: all of the above will still be INVALID. Am I clear enough?

Boris brought the idea of another bug in comment 5; not you. Do you need me to
quote him? Because you said "same thing goes for Boris, every comment since
comment #4 has personally been a waste of time for me". Am I quoting you fair
and square here? And then the bug was re-summarized at comment 19: no mistake
possible here.


> You live in a fantasy world where 98% of the world does not exist, where
nobody uses or code for IE.
You're not only making an ad hominem attack, but you simply ignore the pages I
have coded before, the experience I have in coding for other browsers. You will
never promote your ideas and opinions with personal accusations. People lose
100% of receptivity when they read such comment.
FYI, I reported bugs (and DOM 0 bugs) to MSIE and Opera in the past 6 months.
Opera recruited a software tester regarding standards compliance shortly after
they read my own bug reports on their product.

I am all for smoothing cross-browser incompatibilities across different
browsers. And until incompatibilities can be smoothed, resolved (and in
Mozilla's case, that could take a lot of time ... it depends on the gravity of
the bug actually), I proceed with cross-browser code. Is that approach making
some sort of sense? And if I don't know how this or that browser implements
things or does what, when, how, then I search the web and in 99.9% of the time,
I usually find what I'm looking for or I discover empirically how things work.

If I was not for smoothing up cross-browser incompatibilities, then I would
never have file the bugs I have filed in bugzilla for starters. I have suggested
in the last 2 months in well worded emails (and elsewhere) to update and upgrade
the whole Gecko DOM reference and to add a browser compatibility support section
in detail pages.
I could even quote highly regarded people regarding my own "cross-browser"
contribution: public quotes!


>Could we please go back to fixing this bug?
We? You seem to perceive Mozilla.org like some kind of vending machine or like a
30-min. delivery pizza. Over 4,000 bugs have not been triaged so far. One of my
own bugs has 2 votes but it's still unconfirmed. But your bug filed 2 days ago,
resummarized just a few hours ago, will get, I'm sure, all of the proper,
diligent action and care from Bob, Doron, Ray, Boris, etc.. 

> WHOEVER@mozilla.org seem to agree, and have verified, that this is a bug. Now
we just need to find a resolution.
Keydown and keypress events are pretty much distinct apart from each other: that
is what my zealotting, lengthy, complex, unnecessary, misunderstandable,
confusion and meaningless discussion etc.. led me to discover. I'm all for
having a stopped ("canceled") keydown event (auto-repeat, os defining the repeat
rate and repeat delay) not trigger the keypress event. We don't agree on the
priority, urgency and on the how-to-workaround attitude regarding this bug.

>Now we just need to find a resolution.
From your perspective, you just need others to find a solution for the bugs you
see. And the rest can just be ignored, filtered, bashed, ..whatever..
Comment 22 Bob Clary [:bc:] 2002-09-09 17:43:50 PDT
Created attachment 98520 [details]
rewrite test case to support nn4

Note that NN4 can cancel the input this way. I say, if it is possible in NN4
then we should be compatible with it.

drunclear: ranting gets you nowhere.
Comment 23 Vladimir Ermakov 2002-12-06 11:29:07 PST
*** Bug 174655 has been marked as a duplicate of this bug. ***
Comment 24 xavier.loup 2003-03-11 02:57:30 PST
This documentation (from netscape) explains that if onKeyDown returns false, no
KeyPress events occur.

http://developer.netscape.com/docs/manuals/js/client/jsref/handlers.htm#1120313

The testcase given doesn't work with mozilla.
Comment 25 Bob Clary [:bc:] 2003-03-11 11:57:15 PST
dupe of bug 54035?
Comment 26 Boris Zbarsky [:bz] 2003-03-11 12:04:39 PST
No.
Comment 27 Aaron Leventhal 2004-12-07 13:29:24 PST
(In reply to comment #18) [Boris wrote]
> OK.  I agree that we should try to follow the de-facto standard here unless we
> have _really_ strong reasons not to.

I'm running into this now. Anyone have any issues with me fixing it so that it's
simpler to write cross-browser code?

I hope to fix:
- cancelling onkeydown cancels the onkeypress
- returning false from onkeydown handler effectively cancels

Is that right?

/me hopes the ranters from this bug have gone away and just wants to do the
right thing for cross-browser accessible dhtml.
Comment 28 Boris Zbarsky [:bz] 2004-12-07 13:37:06 PST
Aaron, we should do whatever IE does, basically... If that's exactly what it
does, that's great.
Comment 29 Phil Anderson 2004-12-07 13:44:50 PST
> Aaron, we should do whatever IE does, basically... If that's exactly what it
does, that's great.

Having written a very interactive site that intercepts the backspace key (not
malliciously), I was able to get IE to do it but not in the DOM-3 way.  I'll try
to dredge out my code which allows for this to be done in IE.
Comment 30 Aaron Leventhal 2004-12-07 13:46:07 PST
I just realized, you don't return false to cancel the IE event, you do:
event.returnValue = false

Is that still okay? That's changing a DOM API right?
Comment 31 Hixie (not reading bugmail) 2004-12-07 13:49:20 PST
In http://whatwg.org/specs/web-apps/current-work/#event I wrote that:

| In the ECMAScript DOM binding, the ECMAScript native Function type implements
| the EventListener interface such that invoking the handleEvent() method of the 
| object invokes the function itself, with the evt argument as its only 
| argument. If the function returns false, the event's preventDefault() method 
| must then invoked. Exception: for historical reasons, for the HTML mouseover 
| event, the preventDefault() method must be called when the function returns 
| true instead.

...so I agree.

Does 'keypress' fire before or after 'keyup'? I would think the logical thing to
do would be to make firing 'keypress' be the default action of one of the other
events (and similarly have 'click' be the default action of 'mouseup'). Is that
what IE does, effectively?

I guess I'll have to add a section to Web Apps that defines how keydown, keyup,
textInput and keypress all interact together at some point. Please describe what
you discover IE's behaviour is here so that I don't have to do all the testing
myself, as I don't have access to IE at the moment. :-)
Comment 32 Phil Anderson 2004-12-07 13:50:12 PST
Here is a snippet from some REALLY old code of mine.  It works in IE and safari
(I think) but not in Mozilla:

  if (key==backspace)
  {
    if (navigator.appName=="Microsoft Internet Explorer")
      event.returnValue=false;
    else
      event.preventDefault();
  }
Comment 33 Hixie (not reading bugmail) 2004-12-07 13:52:30 PST
Er, I agree that returning false should cancel. I don't think we should start
changing the Event interface, though. That sounds rather more involved. IE's
event model is rather different than the compliant one, going down this path
could be a slippery slope.
Comment 34 Aaron Leventhal 2004-12-07 14:05:44 PST
(In reply to comment #33)
> Er, I agree that returning false should cancel. I don't think we should start
> changing the Event interface, though. That sounds rather more involved. IE's
> event model is rather different than the compliant one, going down this path
> could be a slippery slope.

Okay.

Just to be clear, I don't think |return false| will cancel the event in IE
though, so we're not gaining any cross-browser scripting compatibility if we
implement that. I tried it and I'm pretty sure you have to set event.returnValue
for IE.
Comment 35 Boris Zbarsky [:bz] 2004-12-07 14:12:17 PST
I don't believe we're planning to do the returnValue thing at this time...
Comment 36 Aaron Leventhal 2004-12-07 14:15:23 PST
Don't shoot me if this is dumb, but should mousedown affect the corresponding
click/mouseup?
Comment 37 Bob Clary [:bc:] 2004-12-07 14:16:01 PST
Created attachment 168161 [details]
keypressdown.html - hacked example from msdn

if you do onkey(down|press)="return handler()" MSIE will cancel the keydown and
prevent the keypress from firing.

Mozilla and MSIE both do keydown then keypress.

Don't do the returnValue emulation.
Comment 38 Aaron Leventhal 2004-12-08 09:23:46 PST
Created attachment 168225 [details] [diff] [review]
Prevent default for onkeydown affects onkeypress and onkeyup

This doesn't do the return false part (is that supposed to preventDefault(),
cancelBubble() or stopPropagation()?). I'm not sure where in the Mozilla code
to make that happen.

This patch only alters the behavior of preventDefault().
Comment 39 Aaron Leventhal 2004-12-08 09:58:26 PST
Great news! return false does preventDefault -- it already worked that way, I
didn't do a thing.
Comment 40 Aaron Leventhal 2004-12-08 10:05:37 PST
Created attachment 168231 [details] [diff] [review]
Testcase shows that onkeydown="return foo();" prevents keypress default action when false is returned, in both IE and Mozilla. Arrow keys in menu should change selected menu item, not scroll the page.
Comment 41 Aaron Leventhal 2004-12-08 10:05:44 PST
Created attachment 168232 [details]
Testcase shows that onkeydown="return foo();" prevents keypress default action when false is returned, in both IE and Mozilla. Arrow keys in menu should change selected menu item, not scroll the page.
Comment 42 Hixie (not reading bugmail) 2004-12-08 10:19:46 PST
(should it cancel onkeyup too? That doesn't seem to make sense, I mean, the key
did come up, cancelling the default action for it going down doesn't stop it
going up, surely.)
Comment 43 Aaron Leventhal 2004-12-08 10:23:20 PST
(In reply to comment #42)
> (should it cancel onkeyup too? That doesn't seem to make sense, I mean, the key
> did come up, cancelling the default action for it going down doesn't stop it
> going up, surely.)

That's easy to change. What do others think?
Comment 44 Bob Clary [:bc:] 2004-12-08 10:52:54 PST
MSIE doesn't cancel keyup if keydown was cancelled.
Comment 45 timeless 2004-12-08 10:57:15 PST
first, there must be a way for me to prevent web pages from annoying me, which
means that gecko must be able to ignore the return values.

second, context menus sometimes appear on mousedown (unix) and sometimes on
mouseup (win), if someone writes a handler that would supress things and uses it
for mouseup, they'll be surprised...

--
reporter: for reference, NO ONE @mozilla.org has touched this bug at all. one
gecko core dev has, and some people who play with standards and evangelism have,
but that's about it.
Comment 46 Aaron Leventhal 2004-12-08 11:36:29 PST
Created attachment 168237 [details] [diff] [review]
Prevent default for keydown affects keypress
Comment 47 neil@parkwaycc.co.uk 2004-12-08 13:20:47 PST
I don't have NS4 handy to compare, but IE handles key events completely
differently to Mozilla.
Mozilla:
Press "." -> keydown event with keyCode = DOM_VK_DECIMAL followed by keypress
event with charCode = 46
Hold "." -> further keypress events with charCode = 46
IE:
Press and hold "." -> multiple keydown events with key = 46 followed by keypress
events with key = 46 unless keydown events cancelled
Comment 48 Aaron Leventhal 2004-12-08 13:28:49 PST
I've seen that too. But it just doesn't seem right to modify Mozilla to make
keydown fire multiple times when a key is held down. I'm sure the spec says what
to do.
Comment 49 Hixie (not reading bugmail) 2004-12-08 13:33:09 PST
I agree with aaron. I think we should fire keydown if the key goes down; if it's
not cancelled, then fire keypress as often as needed; then fire keyup.
Comment 50 Aaron Leventhal 2004-12-08 13:48:50 PST
(In reply to comment #49)
> I agree with aaron. I think we should fire keydown if the key goes down; if it's
> not cancelled, then fire keypress as often as needed; then fire keyup.

I do have to admit to being unsure about it. How will authors develop something
cross-browser that handles repeated keystrokes in a way that doesn't suck?
Comment 51 Aaron Leventhal 2004-12-08 13:53:00 PST
One other difference between IE and Mozilla. Keypress events only happen for
things with ascii values.

So, you really have to use keydown for handling things like arrow keys. However,
if you want arrow keys that are held down to repeat you now have to handle
keypress for Mozilla, and keydown for IE. Doh!
Comment 52 Boris Zbarsky [:bz] 2004-12-08 14:23:19 PST
So... following IE's event model in general is a non-starter, since it disgrees
pretty significantly with the DOM model.

We can do some compat-like hacks, but real compat just isn't happening.
Comment 53 Hixie (not reading bugmail) 2004-12-08 14:35:40 PST
I suppose I could be convinced that keydown could repeat. It just seems so
stupid. So what we're saying is:

   keydown on key down and on key repeat.
     if not cancelled, keypress
   keyup on key up.

Right? For the simple cases, it seems we can get IE compat here. But as bz says,
on the long term, IE's model is so far removed from W3C's that it's a lost cause.
Comment 54 Bob Clary [:bc:] 2004-12-08 15:32:45 PST
Created attachment 168254 [details]
improved keypressdown.html

press/release a
===============
Firefox
keydown   keyCode = 65	
keypress  keyCode = 0	
keyup	  keyCode = 65	

MSIE
keydown   keyCode = 65	
keypress  keyCode = 97	
keyup	  keyCode = 65	

press release down arrow
========================
Firefox
keydown   keyCode = 40	
keypress  keyCode = 40	
keyup	  keyCode = 40	

MSIE
keydown   keyCode = 40	
keyup	  keyCode = 40	

press/hold/release a
====================
Firefox
keydown   keyCode = 65	
keypress  keyCode = 0 
[repeat keydown/keypress]  
keyup	  keyCode = 65	

MSIE
keydown   keyCode = 65	
keypress  keyCode = 97	
[repeat keydown/keypress]
keyup	  keyCode = 65	

press/hold/release down arrow
=============================
Firefox
keydown   keyCode = 40	
keypress  keyCode = 40	
[repeat keydown/keypress]
keyup	  keyCode = 40	

MSIE
keydown   keyCode = 40	
[repeat keydown]
keyup	  keyCode = 40
Comment 55 Aaron Leventhal 2004-12-09 12:59:14 PST
Comment on attachment 168237 [details] [diff] [review]
Prevent default for keydown affects keypress

Bryner suggested I try to patch widget instead. Will work up a patch shortly.
Comment 56 Aaron Leventhal 2004-12-09 18:12:44 PST
Created attachment 168379 [details] [diff] [review]
Don't fire keypress if event status indicates no default
Comment 57 Aaron Leventhal 2004-12-09 18:18:32 PST
Hixie, just to clarify, both the keydown and keypress both get repeated in IE
when a non-ascii key is held down.

And I was surprised to find, at least on Windows, Gecko repeats both events.
Since this code is widget specific I'm not sure if we're consistent.

As a result the menu testcase I attached works identically in IE and Mozilla
when the patch is applied. The arrow keys cycle through the menu repeatedly when
held down.
Comment 58 Hixie (not reading bugmail) 2004-12-09 20:29:08 PST
I'm really confused now. Could you explain exactly what IE's behaviour is, what
Mozilla's behaviour is now, and what you want to change it to? I don't want us
to do any more than necessary to allow cross-browser work -- we certainly don't
want to do silly stuff (like repeating keydown) if we don't have to.
Comment 59 neil@parkwaycc.co.uk 2004-12-10 04:38:00 PST
Comment on attachment 168379 [details] [diff] [review]
Don't fire keypress if event status indicates no default

>Index: widget/src/windows/nsWindow.cpp
Unfortunately OnChar also fires keypress events.
Comment 60 Aaron Leventhal 2004-12-10 06:51:11 PST
Created attachment 168411 [details] [diff] [review]
Make sure we handle WM_CHAR situation in Windows. Also fix another unhandled situation in gtk1 code.
Comment 61 neil@parkwaycc.co.uk 2004-12-10 06:58:09 PST
Comment on attachment 168411 [details] [diff] [review]
Make sure we handle WM_CHAR situation in Windows. Also fix another unhandled situation in gtk1 code.

OK, I don't see anything obviously wrong now.
Comment 62 Boris Zbarsky [:bz] 2004-12-10 07:05:11 PST
I would really like to see jst ok this patch...
Comment 63 Boris Zbarsky [:bz] 2004-12-10 07:06:46 PST
I'm also curious how this change affects sites that did add a separate branch
for Mozilla.  I suspect it should be OK, but it's worth checking out.
Comment 64 Aaron Leventhal 2004-12-15 09:40:09 PST
Comment on attachment 168411 [details] [diff] [review]
Make sure we handle WM_CHAR situation in Windows. Also fix another unhandled situation in gtk1 code.

This patch breaks keyboard navigation in menus. Not sure why I didn't notice
that before.
Comment 65 Aaron Leventhal 2004-12-20 08:06:25 PST
Created attachment 169208 [details] [diff] [review]
Same fix as before, but don't PreventDefault() in menubar's onkeydown listener, otherwise keypress doesn't happen. PreventBubble() and PreventDefault() are enough in that case.
Comment 66 neil@parkwaycc.co.uk 2004-12-20 16:23:38 PST
There is an edge case that this doesn't handle. The issue here is that neither
preventCapture or preventBubble affect propagation in the system event group.
Fortunately there aren't many keydown handlers in the system event group; I
could only find two, one is nsXBLWindowKeyHandler::WalkHandlers and the other
one is nsTextInputListener::KeyDown, both are apparently trying to handle
(gtk2?) native key bindings for html input and textarea elements.
Comment 67 Aaron Leventhal 2004-12-20 17:55:21 PST
Okay, tried another approach, which is working for me on Windows at least:
In this approach Mozilla always fires the keypress event, but initializes it
with NS_EVENT_FLAG_NO_DEFAULT if the keydown had it. This solution also involves
ignoring the prevent default flag in the menulistener's keypress handler, but
that seems okay -- the menu listener always gets the first shot at key events
anyway. This has the advantage of being more correct -- the keypress events
still get fired. 
Comment 68 Aaron Leventhal 2004-12-21 05:42:38 PST
Created attachment 169291 [details] [diff] [review]
Always fire keypress, but do PreventDefault() on it when that had happened on the corresponding keydown. Ignore prevent default flag in menu bar keypress listener.
Comment 69 neil@parkwaycc.co.uk 2004-12-21 06:04:19 PST
Comment on attachment 169291 [details] [diff] [review]
Always fire keypress, but do PreventDefault() on it when that had happened on the corresponding keydown. Ignore prevent default flag in menu bar keypress listener.

Does this work with autorepeat?
Comment 70 Aaron Leventhal 2004-12-21 06:15:12 PST
(In reply to comment #69)
> (From update of attachment 169291 [details] [diff] [review] [edit])
> Does this work with autorepeat?
> 

I tested on Windows -- the only machine I have with me for a while. If you hold
down the arrow key in the menu example I attached, both onkeydown and onkeypress
events repeat, and the preventdefault flag is transferred from keydown to
keypress for each. This is the same as IE.

The code on some of the other platforms looks as if they have a different
assumption about whether keydown should repeat. I think that should be filed as
a separate bug.
Comment 71 Aaron Leventhal 2004-12-23 08:16:19 PST
Related: bug 91592 - KeyDown fires for autorepeated keypresses
Comment 72 Aaron Leventhal 2005-01-16 21:04:34 PST
Neil, am I to take your sr= from the obsolete patch, or do you want to look at
the more recent one? Or, do you need me to request from someone else?
Comment 73 neil@parkwaycc.co.uk 2005-01-17 08:52:33 PST
Comment on attachment 169291 [details] [diff] [review]
Always fire keypress, but do PreventDefault() on it when that had happened on the corresponding keydown. Ignore prevent default flag in menu bar keypress listener.

>+		noDefault  = DispatchKeyEvent(NS_KEY_DOWN, 0, aTranslatedKeyCode);
Nit: just need the one space before = ;-)
Comment 74 Boris Zbarsky [:bz] 2005-01-17 08:55:50 PST
I'd really like jst to OK this change in general....
Comment 75 Johnny Stenback (:jst, jst@mozilla.com) 2005-01-18 17:36:14 PST
Sounds reasonable to me. The DOM spec (working group note) doesn't really offer
much help here, but I think it was supposed to. I'm checking on that, but from
digging through the DOM IG archives it seems like the consensus was to make
canceling of a keydown not cancel the corresponding keyup, but it *should*
prevent the resulting textInput event from being generated. So it seems like
this change is fine wrt compliance with the DOM working group note.
Comment 76 Aaron Leventhal 2005-01-18 18:39:16 PST
Checking in layout/xul/base/src/nsMenuListener.cpp;
/cvsroot/mozilla/layout/xul/base/src/nsMenuListener.cpp,v  <--  nsMenuListener.cpp
new revision: 1.23; previous revision: 1.22
done
Checking in layout/xul/base/src/nsMenuListener.h;
/cvsroot/mozilla/layout/xul/base/src/nsMenuListener.h,v  <--  nsMenuListener.h
new revision: 1.6; previous revision: 1.5
done
Checking in widget/src/beos/nsWindow.cpp;
/cvsroot/mozilla/widget/src/beos/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.88; previous revision: 1.87
done
Checking in widget/src/beos/nsWindow.h;
/cvsroot/mozilla/widget/src/beos/nsWindow.h,v  <--  nsWindow.h
new revision: 1.33; previous revision: 1.32
done
Checking in widget/src/gtk/nsGtkEventHandler.cpp;
/cvsroot/mozilla/widget/src/gtk/nsGtkEventHandler.cpp,v  <--  nsGtkEventHandler.cpp
new revision: 1.187; previous revision: 1.186
done
Checking in widget/src/gtk2/nsWindow.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.127; previous revision: 1.126
done
Checking in widget/src/mac/nsMacEventHandler.cpp;
/cvsroot/mozilla/widget/src/mac/nsMacEventHandler.cpp,v  <--  nsMacEventHandler.cpp
new revision: 1.167; previous revision: 1.166
done
Checking in widget/src/os2/nsWindow.cpp;
/cvsroot/mozilla/widget/src/os2/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.185; previous revision: 1.184
done
Checking in widget/src/photon/nsWidget.cpp;
/cvsroot/mozilla/widget/src/photon/nsWidget.cpp,v  <--  nsWidget.cpp
new revision: 1.119; previous revision: 1.118
done
Checking in widget/src/qt/nsCommonWidget.cpp;
/cvsroot/mozilla/widget/src/qt/nsCommonWidget.cpp,v  <--  nsCommonWidget.cpp
new revision: 1.10; previous revision: 1.9
done
Checking in widget/src/windows/nsWindow.cpp;
/cvsroot/mozilla/widget/src/windows/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 3.534; previous revision: 3.533
done
Checking in widget/src/windows/nsWindow.h;
/cvsroot/mozilla/widget/src/windows/nsWindow.h,v  <--  nsWindow.h
new revision: 3.194; previous revision: 3.193
done
Checking in widget/src/xlib/nsAppShell.cpp;
/cvsroot/mozilla/widget/src/xlib/nsAppShell.cpp,v  <--  nsAppShell.cpp
new revision: 1.91; previous revision: 1.90
done
Comment 77 Robert Kaiser (not working on stability any more) 2005-01-19 18:02:40 PST
can this be the case that Mozilla swallow fast key typing on my machine in a new
trunk build?
I had no problem yesterday, but today it has worsened much.

Actually, in mail compose, letters I type get swollowed if I'm fast enough,
which seems to not happen on other text boxes, but all text boxes in this build
do not react well to auto-repeating arrow keys (takes about a second to see the
caret move one character)...
Comment 78 Aaron Leventhal 2005-01-20 06:43:25 PST
(In reply to comment #77)
> can this be the case that Mozilla swallow fast key typing on my machine in a new
> trunk build?
Probably. Please file a new bug assigned to me and provide platform/product details.
Comment 79 Christian :Biesinger (don't email me, ping me on IRC) 2005-01-20 11:34:18 PST
swallowed keys are bug 279152
Comment 80 Doron Rosenberg (IBM) 2005-04-06 14:36:43 PDT
On gtk2 seamonkey, a VK_RETURN event in a xul:textbox (user presses enter) in a
dialog has getPreventDefault be true.  On windows, it is false.

A place to debug this is
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/dialog.xml#290
.  Good example is the find dialog (ctrl-f), pressing enter in the textbox
doesn't work on gtk2.
Comment 81 Christian :Biesinger (don't email me, ping me on IRC) 2005-04-06 15:17:37 PDT
doron: isn't that Bug 288729?
Comment 82 Doron Rosenberg (IBM) 2005-04-06 16:26:17 PDT
Right, but it seems related to this fix (very little testing seems to indicate).
Comment 83 Boris Zbarsky [:bz] 2005-05-15 23:25:44 PDT
This caused bug 290131
Comment 84 Boris Zbarsky [:bz] 2005-05-17 10:26:32 PDT
And likely bug 291099
Comment 85 Jesse Ruderman 2005-12-05 03:37:24 PST
This change also caused bug 318525, which I marked as invalid.

Note You need to log in before you can comment on or make changes to this bug.