New issue
Advanced search Search tips

Issue 849263 link

Starred by 2 users

Issue metadata

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



Sign in to add a comment

Inconsistent selection and enter behaviour while composing Korean

Reported by k.krz...@cksource.com, Jun 4 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce the problem:
This is the same problem as reported in https://bugs.chromium.org/p/chromium/issues/detail?id=653160. However, here we focus on what `document.getSelection()` reports.

1. Install and switch to Korean keyboard Microsoft IME.
2. Go to any element with "contenteditable=true" (probably same with text inputs but haven't checked).
3. Make sure you are able to view real time selection (e.g. via logging).
4. Start typing Korean. 
5. Press enter.

This case can be easily checked on this codepen - https://codepen.io/f1ames/pen/yEerNG?editors=1010

What is the expected behavior?
I'm not daily Korean user so it is hard to say if caret should be before or after last composed character. According to already linked issue (https://bugs.chromium.org/p/chromium/issues/detail?id=653160) the caret should be after last character.

I would expect consistent behaviour. When selection is before last character and I press enter, everything after selection is moved to the new line.

What went wrong?
When selection is before last character and I press enter, only selection is moved to a new line. The character which is after the selection stays in the previous line.

From the API perspective, the main issue is that when accessing selection object (`document.getSelection()`) it shows that selection is before the last character, but when you press enter, the behaviour is like the selection was after this character. This is inconsistent with all other cases (not composing Korean) where for such selection characters after is also moved to a new line when pressing enter.

As the selection is exactly the same as during normal typing like `Foo Ba|r` (| is the caret position), there is no way to determine that for Korean the behaviour may be different. For all applications (especially editors) which in any way manipulates selection or relay on its position when mapping DOM structure (or any other stuff) it will simply break.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 66.0.3359.181  Channel: stable
OS Version: Tested on Windows 10 and 7
Flash Version: 

There are probably few solutions:

* Fixing https://bugs.chromium.org/p/chromium/issues/detail?id=653160 so the selections will be placed after the last character (or making it consistent with other browsers - see the other issue for details) which will solve the problem.
* Making possible to distinguish selection in this case with selection form other cases so you know the behaviour will be different (now these selections are identical).
* Any other approach which works :)
 
IME_KOREAN.gif
27.5 KB View Download
Labels: Needs-Triage-M66
Cc: phanindra.mandapaka@chromium.org
Labels: Triaged-ET M-69 Target-69 FoundIn-69
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on reported chrome version 66.0.3359.181 & latest stable 67.0.3396.62  and on latest chrome 69.0.3450.0 using Windows 10. 
 
Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged.

Note:This issue related to only Windows.

Thanks! 

Comment 3 by yosin@chromium.org, Jun 13 2018

Components: -Blink>Editing Blink>Editing>Selection
Labels: -Pri-2 Pri-3
Status: Available (was: Untriaged)

Sign in to add a comment