657265 - Input goes to wrong element if focus changes during keypress

Status: UNCONFIRMED

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

Description

[Sidney San Martín]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.68 Safari/534.24
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

If an element is focused from a keypress event listener, the input doesn’t go to the newly-focused element.

Reproducible: Always

Steps to Reproduce:
1. Create a testcase wherein pressing a key when an input is not focused causes the input to be focused, in the keypress event.
2. Press a key which represents a character (e.g. the A key)

Actual Results:  
The input gains focus and a character appears in the input.

Expected Results:  
The input gains focus, no character appears

This works in all the other browsers I tried: Safari 5, Chrome 11, Opera 11, and Internet Explorer 9

The DOM Level 3 spec for keypress (<http://www.w3.org/TR/DOM-Level-3-Events/#event-type-keypress>) indicates that keypress fires “…before the processing of an input method editor", and it lists textInput as a default action of keypress.

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keypress

Comment 2

[Boris Zbarsky [:bzbarsky]]

"input method editor" doesn't mean the editor of a textfield, for what it's worth.

And the textinput even is not what causes the character insertion; the keypress event is.

The compat issue here is sad; it seems to me that the other browsers' behavior is clearly buggy, since the insertion of the character happens as part of the default action of the keypress event on the input, in the most obvious mental model of this.

Note that DOM3 Events doesn't actually say anything about entering any characters in the input field, so a strict implementation of the spec would never enter any text at all.  This is clearly a spec bug.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #2)
> Note that DOM3 Events doesn't actually say anything about entering any
> characters in the input field, so a strict implementation of the spec would
> never enter any text at all.  This is clearly a spec bug.
It is not up DOM 3 Event specify how HTML elements behave.

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK, fair.  Then who's supposed to specify which event triggers insertion of text into a text input?  The HTML spec certainly doesn't, last I checked.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I feel the expected behavior strange. It means that users cannot know which element will receive their key input. Doesn't this cause something security risk?

Comment 6

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.