Closed Bug 1568996 Opened 2 years ago Closed 2 years ago

Inconsistent Behavior with Delete Key events in Firefox 68+


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

68 Branch



Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- verified


(Reporter: akirose, Assigned: m_kato)




(Keywords: regression)


(1 file, 1 obsolete file)

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.

Flags: needinfo?(nika)

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

Component: General → Editor
Flags: needinfo?(nika) → needinfo?(masayuki)
Product: Firefox → Core
Flags: needinfo?(masayuki)

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)

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

Has Regression Range: --- → yes
Ever confirmed: true

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

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?

Assignee: nobody → 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.

Priority: -- → P2
Attachment #9096829 - Attachment is obsolete: true
Flags: needinfo?(masayuki)
Attachment #9097097 - Attachment description: Bug 1568996 - Flush layout before calling nsFrameSelection::MoveCaret. → Bug 1568996 - Flush layout before calling nsFrameSelection::MoveCaret. r=masayuki
Pushed by
Flush layout before calling nsFrameSelection::MoveCaret. r=masayuki
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Regressions: 1595425

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.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.