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)
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
Updated•7 years ago
|
Component: Untriaged → DOM: Events
Product: Firefox → Core
Updated•7 years ago
|
Priority: -- → P2
Reporter | ||
Comment 2•7 years ago
|
||
Any idea if this issue is valid? If so is there any ETA.
Comment 3•3 years ago
|
||
I'm not seeing the testcase behaving differently to other browsers.
Flags: needinfo?(bugs)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•