aborted drag-and-drop from a textarea makes the caret (text cursor) permanently displayed at the same place
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
People
(Reporter: vincent-moz, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:137.0) Gecko/20100101 Firefox/137.0
Steps to reproduce:
In a webpage with several textareas (or one, for up to step 5), e.g. in Bugzilla when reporting a new bug:
- Select some text in a textarea.
- Initiate a drag-and-drop: drag the selection.
- Before releasing the mouse button, type the Esc key to abort the drag-and-drop.
- Release the mouse button.
- Click at various places in the textarea and edit.
- Click in another textarea and edit.
Actual results:
After step 4, the caret remains at the same place, even when clicking and editing in a different textarea (which does not get a text cursor displayed). Note that this is only a display issue of the caret: one can edit normally, but without a caret visible at the right place.
Expected results:
The caret should be displayed where the actual editing position is.
A similar, but different bug (since drag-and-drop was not involved, and the bug effect is a bit different): bug 1917823.
|
||
Comment 1•4 months ago
|
||
I can't reproduce on macOS. Testing with https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13689
Description
•