This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24738 - D3E spec should define if keypress is fired when preceding beforeinput is consumed by preventDefault()
Summary: D3E spec should define if keypress is fired when preceding beforeinput is con...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-20 03:00 UTC by Masayuki Nakano
Modified: 2014-04-07 23:17 UTC (History)
4 users (show)

See Also:

Attachments

Description Masayuki Nakano 2014-02-20 03:00:21 UTC 
D3E spec should define if keypress is fired when preceding beforeinput is consumed by preventDefault().

I think that keypress shouldn't be fired because:

* it's not necessary for the web apps which handle beforeinput
* not dispatching keypress doesn't waste the resource (CPU, battery)
Comment 1 Gary Kacmarcik 2014-04-07 22:38:34 UTC 
Since keypress is deprecated, there is no need to define how it operates WRT beforeinput.

And defining how this deprecated event should interact with the new events may make it more difficult for browsers to implement the new behavior.

So, it seems best to leave this unspecified.
Comment 2 Boris Zbarsky 2014-04-07 22:41:59 UTC 
Given the amount of keypress usage out there, in practice it _will_ be used in combination with the new events, and we will need UAs to be interoperable in that setting.  So we do in fact need to spec this.
Comment 3 Gary Kacmarcik 2014-04-07 23:17:21 UTC 
I've updated the spec (ED) to mention that keypress (if supported) should be suppressed if keydown is cancelled.

However, we are not attempting to specify all possible interactions between the legacy events and the new events - partially because we don't want to needlessly constrain user agents implementing the new events and partially because many legacy events are not consistent across all user agents.

But you're right that it makes sense to include that information when it is straightforward - as it is with this bug.