Emoji inserted in wrong place after setting caret asynchronously via selection API
Reported by
teleclim...@gmail.com,
Mar 7 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Open the file attached 2. click in the text to focus contenteditable and place caret in text 3. press "tab" key to relocate the caret to a different position using the selection API. 4. press ctrl + cmd + space to summon Mac emoji insertion dialog 5 double click on an emoji to insert it. What is the expected behavior? The emoji should be inserted where the caret is blinking What went wrong? The emoji was inserted at the position we originally clicked (step 2) Did this work before? No Does this work in other browsers? Yes Chrome version: 56.0.2924.87 Channel: stable OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 24.0 r0 This works fine in Safari. I don't know if it works on Windows or not, I couldn't find an equivalent for the emoji dialog on my Win 7 machine. Note that the setTimeout is important. Things work as expected if you call setCaret directly from the event handler. Thanks!
,
Mar 7 2017
Tested in Canary (59.0.3032.0) and the problem is still there.
,
Mar 7 2017
,
Mar 7 2017
Able to reproduce this issue on Mac 10.12.3 using chrome reported version #56.0.2924.87 and latest canary #59.0.3032.0. This is a non-regression issue as it is observed from M50 old builds. From M-45 and older builds on pressing tab key(step 3), the focus moves to chrome address bar rather than relocating the caret to a different position using the selection API. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Mar 10 2017
,
Mar 13 2017
Could you try to use Selection#collpase() instead of removeAllRanges() and addRange()? It seems that losing focus by Selection#removeAlLRanges() causes this. (But not sure) Put a sample into https://jsfiddle.net/sdkvoqkv/
,
Mar 13 2017
Here is a fiddle using Selection.collapse, which exhibits the same problem as originally reported. https://jsfiddle.net/teleclimber/sdkvoqkv/1/ I also tried with Selection.modify with the same result. thanks
,
Mar 13 2017
Thank you for providing more feedback. Adding requester "yosin@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 21 2017
Able to reproduce this issue on Mac 10.12.3 using chrome reported version #56.0.2924.87 and latest canary #59.0.3046.0. This is a non-regression issue as it is observed from M50 old builds.From M-48 and older builds on pressing tab key(step 3), the focus moves to chrome address bar rather than relocating the caret to a different position using the selection API. Hence, marking it as untriaged to get more inputs from dev team. Please find the attached screencast for reference. Note: Issue specific to Mac OS. Thanks...!!
,
Apr 6 2017
,
Oct 4 2017
,
Oct 4
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 5
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 Deleted