New issue
Advanced search Search tips
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
link

Issue 698947: 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

Comment 2 by teleclim...@gmail.com, Mar 7 2017

Looks like the file attachment got lost. here it is again.
index.html
838 bytes View Download

Comment 3 by teleclim...@gmail.com, Mar 7 2017

Here is a gif if that helps.
mac-ce-bug.gif
230 KB View Download

Comment 4 by teleclim...@gmail.com, Mar 7 2017

Tested in Canary (59.0.3032.0) and the problem is still there.

Comment 5 by nyerramilli@chromium.org, Mar 7 2017

Labels: Needs-Triage-M56

Comment 6 by krajshree@chromium.org, Mar 7 2017

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...!!

Comment 7 by spqc...@chromium.org, Mar 10 2017

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/

Comment 9 by teleclim...@gmail.com, 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

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

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

Comment 11 by jmukthavaram@chromium.org, Mar 21 2017

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

Comment 12 by yosin@chromium.org, Apr 6 2017

Status: Available (was: Untriaged)

Comment 13 by yosin@chromium.org, Oct 4 2017

Labels: Pri-3

Comment 14 by sheriffbot@chromium.org, Oct 4

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

Comment 15 by yosin@chromium.org, Oct 5

Status: Available (was: Untriaged)

Sign in to add a comment