New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 698947 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Emoji inserted in wrong place after setting caret asynchronously via selection API

Reported by teleclim...@gmail.com, Mar 7 2017

Issue description

UserAgent: 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!

 

Comment 1 Deleted

Looks like the file attachment got lost. here it is again.
index.html
838 bytes View Download
Here is a gif if that helps.
mac-ce-bug.gif
230 KB View Download
Tested in Canary (59.0.3032.0) and the problem is still there.
Labels: Needs-Triage-M56
Components: UI
Labels: -Needs-Triage-M56 M-59
Status: Untriaged (was: Unconfirmed)
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...!!
Components: -UI Blink>Editing

Comment 8 by yosin@chromium.org, Mar 13 2017

Components: -Blink>Editing Blink>Editing>Selection
Labels: Needs-Feedback
Status: Unconfirmed (was: Untriaged)
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/


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
Project Member

Comment 10 by sheriffbot@chromium.org, Mar 13 2017

Cc: yosin@chromium.org
Labels: -Needs-Feedback
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
Status: Untriaged (was: Unconfirmed)
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...!!
698947.mp4
2.1 MB View Download
Status: Available (was: Untriaged)
Labels: Pri-3
Project Member

Comment 14 by sheriffbot@chromium.org, Oct 4

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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
Status: Available (was: Untriaged)

Sign in to add a comment