Open Bug 1401222 Opened 7 years ago Updated 2 years ago

Key events re-queued out of order if focus changes on keydown

Categories

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

52 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: chris.rullan, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce:

https://jsfiddle.net/oendh5ex/2/

Note I am on ESR 52.3

Setup:
Have a focusable element, with some child content (div with tabIndex, child span)
Register a keydown listener on the outer element
On keydown remove the child content (span) and add a focusable element as a child (input text), and call focus on the new child (input text)

Interaction:
Tab to the focusable outer element. Press 2 keys as consecutively as possible (very fast). In my example press 'a' then 'b' almost simultaneously.

Or just use the fiddle above and tab to the wrapper div and press 2 keystrokes as described.


Actual results:

The keydown 'a' fires, but the keypress 'a' does not immediately follow. Instead you get keydown 'a', keydown 'b', keypress 'b', keydown 'a', keypress 'a' which results in the incorrect input order. Detailed event list below.

focus div#wrapper
keyup charCode=0, keyCode=9 div#wrapper
keydown charCode=0, keyCode=65 » div#wrapper
DOMNodeRemoved span#i1
DOMSubtreeModified div#wrapper
DOMNodeInserted input#i2 property value = ""
DOMSubtreeModified div#wrapper
blur div#wrapper
keydown charCode=0, keyCode=66 » input#i2 property value = ""
keypress charCode=98, keyCode=0 » input#i2 property value = ""
input  » input#i2 property value = "b"
keydown charCode=0, keyCode=65 » input#i2 property value = "b"
keypress charCode=97, keyCode=0 » input#i2 property value = "b"
input  » input#i2 property value = "ba"
keyup charCode=0, keyCode=65 » input#i2 property value = "ba"
keyup charCode=0, keyCode=66 » input#i2 property value = "ba"
change  » input#i2 property value = "ba"


Expected results:

I would not expect the keydown and keypress to be re-fired as it seems they are. Both Chrome and Edge just continue their events with the new focus target. I expect the input to always get the events in order 'a' then 'b'.

CHROME events:
focus
keyup {key: "Tab", code: "Tab"¿}
blur
keydown {key: "a", code: "KeyA"¿}
keypress {key: "a", code: "KeyA"¿}
input {data: "a" ¿}
keydown {key: "b", code: "KeyB"¿}
keypress {key: "b", code: "KeyB"¿}
input {data: "b"¿}
keyup {key: "a", code: "KeyA"¿}
keyup {key: "b", code: "KeyB"¿}

EDGE events:
focus
keyup keyCode=9
keydown char=a keyCode=65
blur
keypress char=a charCode=97
input
keydown char=b keyCode=66
keypress char=b charCode=98
input
keyup char=a keyCode=65
Component: Untriaged → DOM: Events
Product: Firefox → Core
Is there a guarantee of input event order?
Flags: needinfo?(bugs)
Priority: -- → P2
Any idea if this issue is valid? If so is there any ETA.

I'm not seeing the testcase behaving differently to other browsers.

Flags: needinfo?(bugs)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.