Closed Bug 167145 Opened 21 years ago Closed 18 years ago

cancelling keydown does not affect corresponding keypress/keyup

Categories

(Core :: DOM: Events, defect, P3)

Product:
Core
Component:
DOM: Events
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bugzilla.mozilla.org, Assigned: aaronlev)

References

(
URL
)

Details

(Keywords: access, dom0, dom1)

Attachments

(5 files, 7 obsolete files)

Stopping the keydown propagation; preventing default action of keypress event.
6.69 KB, text/html
Details
rewrite test case to support nn4
2.26 KB, text/html
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.
15.09 KB, text/html
Details
improved keypressdown.html
964 bytes, text/html
Details
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
bryner
: review+
neil
: superreview+
Details | Diff | Splinter Review 
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This impacts dom0 and dom1 standards compatibility:
DOM0 (property assignment) and DOM1 (addEventListener)

Downgrading, this is not a blocker.  Adding jst
Severity: blocker → major
Keywords: dom0, dom1
Summary: Input events cannot be cancelled → Key events cannot be cancelled
*** Bug 147865 has been marked as a duplicate of this bug. ***
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?"
Whiteboard: DUPEME
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...
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.
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?
That's by design.  See the table in section 2 at
http://www.mozilla.org/editor/key-event-spec.html
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.
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.
Is comment #10 about event.keyCode being 0 or about the original topic?
About event.keycode. Which we should take to that bug if we discuss it further.
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.
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.
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 # 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.
Priority: -- → P1
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.
Priority: P1 → --
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...
Summary: Key events cannot be cancelled → cancelling keydown does not affect corresponding keypress/keyup
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.
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.
> 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..
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.
*** Bug 174655 has been marked as a duplicate of this bug. ***
Severity: major → normal
Priority: -- → P3
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.
Assignee: joki → aaronleventhal
(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.
Keywords: access
Aaron, we should do whatever IE does, basically... If that's exactly what it
does, that's great.
> 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.
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?
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. :-)
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();
  }
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.
(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.
I don't believe we're planning to do the returnValue thing at this time...
Don't shoot me if this is dumb, but should mousedown affect the corresponding
click/mouseup?
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.
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().
Attachment #168225 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #168225 - Flags: review?(bryner)
Great news! return false does preventDefault -- it already worked that way, I
didn't do a thing.
Attachment #168231 - Attachment is obsolete: true
(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.)
(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?
MSIE doesn't cancel keyup if keydown was cancelled.
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.

        Attachment #168225 -
        Attachment is obsolete: true

    
  

        Attachment #168225 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #168225 -
        Flags: review?(bryner)

    
  

        Attachment #168237 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #168237 -
        Flags: review?(bryner)

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
(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?

    
    

    
  
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!

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  


  
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

        Attachment #168161 -
        Attachment is obsolete: true

    
    

    
  
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.

        Attachment #168237 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #168237 -
        Flags: review?(bryner)

    
    

    
  


  

        Attachment #168237 -
        Attachment is obsolete: true

    
  

        Attachment #168379 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #168379 -
        Flags: review?(bryner)

    
    

    
  
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.

    
    

    
  
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 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.

    
  

        Attachment #168379 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #168379 -
        Flags: review?(bryner)

    
  

        Attachment #168411 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #168411 -
        Flags: review?(bryner)

    
    

    
  
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.

        Attachment #168411 -
        Flags: superreview?(neil.parkwaycc.co.uk) → superreview+

    
    

    
  
I would really like to see jst ok this patch...

    
    

    
  
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 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.

        Attachment #168411 -
        Attachment is obsolete: true

        Attachment #168411 -
        Flags: review?(bryner)

    
  

        Attachment #169208 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #169208 -
        Flags: review?(bryner)

    
    

    
  
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.

    
  

        Attachment #169208 -
        Attachment is obsolete: true

        Attachment #169208 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #169208 -
        Flags: review?(bryner)

    
    

    
  
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 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?

    
    

    
  
(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.

    
    

    
  
Related: bug 91592 - KeyDown fires for autorepeated keypresses

    
  

        Attachment #169291 -
        Flags: review?(bryner)

        Attachment #169291 -
        Flags: review?(bryner) → review+

    
    

    
  
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 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 = ;-)

        Attachment #169291 -
        Flags: superreview?(neil.parkwaycc.co.uk) → superreview+

    
    

    
  
I'd really like jst to OK this change in general....

    
    

    
  
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.

    
    

    
  
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
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED

    
    

    
  
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)...

    
    

    
  
(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.

    
    

    
  
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.

    
    

    
  
Right, but it seems related to this fix (very little testing seems to indicate).

    
    

    
  
This caused bug 290131
Depends on: 290131

    
    

    
  
And likely bug 291099
Depends on: 291099

    
  
Blocks: 317245

    
    

    
  
This change also caused bug 318525, which I marked as invalid.
Depends on: 318525

    
  
Whiteboard: DUPEME

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