Closed Bug 1568996 Opened 1 year ago Closed 10 months ago

Inconsistent Behavior with Delete Key events in Firefox 68+

Categories

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

68 Branch
defect

Tracking

()

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

People

(Reporter: akirose, Assigned: m_kato)

References

()

Details

(Keywords: regression)

Attachments

(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

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!

Status: UNCONFIRMED → NEW
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
Attachment #9097097 - Attachment description: Bug 1568996 - Flush layout before calling nsFrameSelection::MoveCaret. → Bug 1568996 - Flush layout before calling nsFrameSelection::MoveCaret. r=masayuki
Pushed by m_kato@ga2.so-net.ne.jp:
https://hg.mozilla.org/integration/autoland/rev/246acf391102
Flush layout before calling nsFrameSelection::MoveCaret. r=masayuki
Status: NEW → RESOLVED
Closed: 10 months 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.

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