1568996 - Inconsistent Behavior with Delete Key events in Firefox 68+

Status: VERIFIED FIXED

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

Description

[Aki Rose Braun [:akirose]]

Given an input text element with event listeners on keydown and input, typically when pressing a key first the keydown event fires, then the input event fires. If the input's value is modified in the keydown event handler, the cursor selection is reset to the end of the input element and the input event will not fire.

Expected behavior:
By setting the selection of the cursor after the value has been modified, cursor position is recovered and input event fires as expected.

Actual behavior:
As of Firefox 68, when the delete key ⌦ ("forward" delete) is used, the key is never entered and the input event never fires, even when adjusting the selection.

See attached URL for more detailed explanation of the bug, as well as a functional demo.

Comment 1

[Nika Layzell [:nika] (ni? for response)]

Thanks for the bug report & minimized repro test case! Forwarding to :masayuki & the Editor component.

Comment 2

[Alexandru Trif, Desktop QA [:atrif]]

Hello! Using the test case I managed to find a regression range:

Last good revision: 9af23c413a1f8d337b19b4f8450e241e91b71136 (2017-06-29)
First bad revision: 587daa4bdc4b40b7053f4ca3b74723ca747f3b52 (2017-06-30)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9af23c413a1f8d337b19b4f8450e241e91b71136&tochange=587daa4bdc4b40b7053f4ca3b74723ca747f3b52

Unfortunately, I cannot get a smaller range. If more information is needed please let me know. Thank you!

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

According to the regression range, could be caused by bug 1375910, but I have no idea how it causes this regression.

Comment 4

[Makoto Kato [:m_kato]]

Interesting. If not using e10s, this doesn't occur, so this is only e10s. And this seems that CharacterExtendForDelete returns failure due to dirty frame. Why e10s only?

Comment 5

[Makoto Kato [:m_kato]]

nsFrameSelection calls FlushPendingNotifications, but it doesn't flush layout since this is during script blocker. So I don't think that this is regression by bug 1375910.

Comment 6

[Makoto Kato [:m_kato]]

Attachment: Bug 1568996 - Flush layout before calling nsFrameSelection::MoveCaret.

Comment 7

[Makoto Kato [:m_kato]]

Attachment: Bug 1568996 - Flush layout before calling nsFrameSelection::MoveCaret. r=masayuki

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/246acf391102
Flush layout before calling nsFrameSelection::MoveCaret. r=masayuki

Comment 9

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/246acf391102

Comment 10

[Alexandru Trif, Desktop QA [:atrif]]

Hello! Reproduced the issue using Firefox 70.0a1 (20190725215157) on Windows 10x64 and the attached test case.
The issue is verified fixed using Firefox 71.0b11 (20191118154140) on Windows 10x64 macOS 10.14 and Ubuntu 18.04.