Bug 16976 – caret position needs to be set *before* firing/handling input events

• Component: HTML Editing
• Status: RESOLVED CONFIGURATION CHANGED

[Tim S]

Editor::appliedEditing currently dispatches input events and after sets the selection (caret) to the end of the text. This means when handling an input event, you cannot modify the selection without being 'trumped' by this later setting by appliedEditing. 

I tried making a patch to fix this by simply moving one line in this method, dispatchEditibleContentChangedEvents, 5 lines down so it occurs after the call to setSelection. I created a layout test to verify (see attached). However, the patch causes two layout tests to fail: fast/forms/drag-into-textarea.html and fast/forms/drag-out-of-textarea.html. The output differs in these two tests because rather than cut/pasting, the drag an drop results in both fields being empty or both fields containing the text, respectively. The expected output is correct and I don't think it should be changed, so this attempt to fix breaks text drag and drop, but I'm not sure why.

[Tim S]

Created attachment 18602 [details]
test that caret selection is set before firing input event

currently fails on recent c.o @ r29678

[Eric Seidel (no email)]

The test passes in FF and Opera, and does not actually execute cleanly in IE.

[Adam Roben (:aroben)]

<rdar://problem/5766949>

[Ahmad Saleem]

I am unable to reproduce this bug in Safari 15.6 on macOS 12.5 using attached test case and as soon as I type something in <input> field, I get "test passed" and it is same across all other browsers (Firefox Nightly 105 and Chrome Canary 106). I think it got fixed along the way and this can be marked as "RESOLVED CONFIGURATION CHANGED". Thanks!