Issue metadata
Sign in to add a comment
|
Textarea selectionStart and selectionEnd props don't ALWAYS updated by the time the click handler is fired
Reported by
sharon...@gmail.com,
Dec 14
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 Steps to reproduce the problem: 1. Double click on any word to select it. 2. Once the word is selected, single left click on it again, to deselect it. Now the caret is flashing somewhere inside the previously selected word. What is the expected behavior? I expected that by the time the click handler was called the selectionStart and selectionEnd properties had been already updated. What went wrong? Even though that visually the selection was replaced with a flashing caret, the selectionStart and selectionEnd properties still belonged to the previous selection when the click hanlder was called. However it got updated eventually: if you move the mouse out from the textarea in the attached example, you see the updated value. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 73.0.3639.1 (Official Build) canary (32-bit) (cohort: Clang-32) Channel: canary OS Version: 10.0 Flash Version: 32.0.0.105 When I click any other word but the selected one, both the selectionStart and selectionEnd properties update by the time the click hanlder is called. Firefox updates the properties by the time the click event hanlder is called irrecpective to what was selected before. In Edge, clicking on a selected word sets both selectionStart and selectionEnd to zero. Clicking on an unselected word, the selection properties updates correctly by the time the click hanlder is called.
,
Dec 15
,
Dec 17
I confirmed this was reproducible with <div contenteditable=true>. Firefox works as expected, that is to say, single click shows collapsed selection.
,
Jan 10
Since Chrome sets selection after dispatching focus event, selection{Start,End} hold previous value.
We track this issue by 919540
,
Jan 10
I think this issue is not a duplicate of 919540, since that one is talking about the focus event.
On that issue you wrote the following:
“* SelectionController::HandleMousePressEvent() -> **update selection then dispatch "click" event**”
So one can righly expect that by the time the click handler is called, the selection{Start,End} holds the new value.
Which is true most of the time, expect when there was a selection AND one clicks somewhere on that selection range.
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by sharon...@gmail.com
, Dec 14