Issue metadata
Sign in to add a comment
|
Cannot enter composite characters directly after span element
Reported by
joergeis...@gmail.com,
Nov 30 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Example URL: https://jsfiddle.net/joeeisenhardt/z3w7gkx7/3/ Steps to reproduce the problem: 1. load the above fiddle 2. switch input locale to use IME (e.g. Chinese, Japanese, or Korean) 3. Asian characters can be entered in between the text 4. Try entering Asian characters at first position, directly after the span element What is the expected behavior? Expectation is that, independent of the position in the text, Asian characters can be entered What went wrong? Asian character cannot be entered at fist position after the span. (Note: entering these characters in the middle of the text works fine) The IME gets activated, composite characters are partially entered, and then further keystrokes are no longer accepted. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 62.0.3202.94 Channel: stable OS Version: 10.0 Flash Version:
,
Dec 4 2017
Able to reproduce the issue on Windows 10 and Ubuntu 14.04 using chrome reported version #62.0.3202.94 and latest canary #64.0.3282.7. Issue is not seen in OS-Mac. Bisect Information: ===================== Good build: 52.0.2734.0 Revision(393126) Bad Build : 52.0.2735.0 Revision(393409) Note: Providing the change log from omahaproxy as the per revision bisect script got interrupted due to perf builds. Change Log URL: (From Omahaproxy) https://chromium.googlesource.com/chromium/src/+log/52.0.2734.0..52.0.2735.0?pretty=fuller&n=10000 From the above change log suspecting below change Review-Url: https://codereview.chromium.org/1970573004 rego@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks...!!
,
Dec 4 2017
,
Dec 4 2017
This is completely unrelated to my change, as that patch only affects Grid Layout (which is not used on the example) and the parsing of a property. Taking a look to the bisect this can be related to compositing text: https://codereview.chromium.org/1847583003 Assigning to @yabinh to take a look.
,
Dec 4 2017
,
Dec 6 2017
yabinh@ left the team. The root cause is inside InsertIncrementalTextCommand.
,
Jan 10 2018
rlanday@, could you take look? Thanks!
,
Jan 23 2018
The problem seems unrelated to InsertIncrementalTextCommand. The CL rego@ found does look appear relevant.
The markup that triggers the issue is as follows:
<div contenteditable='true'>
<span contenteditable='false' draggable='false'>SPAN1</span><!--
-->Unable to enter composite characters after span.<!--
--><span contenteditable='false' draggable='false'>SPAN2</span>
</div>
The problem is that after the first character is entered, the ending selection we get from TypingCommand::InsertText() that should contain the first character actually starts before the end of the first <span>, in a non-editable region. Trying to replace a selection that starts in a non-editable region fails, so we cancel out the composition.
The fix seems to be to change:
// Find out what node has the composition now.
const Position base = MostForwardCaretPosition(selection.Base());
to
// Find out what node has the composition now.
const Position base = MostForwardCaretPosition(selection.Base(), kCanCrossEditingBoundary);
in InputMethodController::SetComposition(). We also need to allow the base node to be a non-text node; for some reason, MostForwardCaretPosition() doesn't seem to actually move the position into the text node; it leaves it immediately before. Alternatively, maybe we could find a way to fix this behavior?
,
Jan 23 2018
It seems that using kCanSkipOverEditingBoundary instead of kCanCrossEditingBoundary fixes the problem with the selection base not moving into the text node. What's the difference between these?
,
Jan 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/15af5c52502c2921a759b9a72dea76aa70bac14d commit 15af5c52502c2921a759b9a72dea76aa70bac14d Author: Ryan Landay <rlanday@chromium.org> Date: Tue Jan 23 20:26:45 2018 Fix bug composing text with IME immediately after non-editable element When an IME tries to set a composition immediately after a non-editable element inside an editable region, it's possible for the selection base to get stuck inside the non-editable region, in which case the attempt to replace the selection fails. The fix is to pass the kCanSkipOverEditingBoundary flag when we call MostForwardCaretPosition() on the selection base so we can find the actual editable region. Bug: 790777 , 801441 Change-Id: I1014901742671f6fbb153c7117eaa1b271a265f7 Reviewed-on: https://chromium-review.googlesource.com/879839 Commit-Queue: Ryan Landay <rlanday@chromium.org> Reviewed-by: Yoshifumi Inoue <yosin@chromium.org> Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org> Cr-Commit-Position: refs/heads/master@{#531330} [modify] https://crrev.com/15af5c52502c2921a759b9a72dea76aa70bac14d/third_party/WebKit/Source/core/editing/ime/InputMethodController.cpp [modify] https://crrev.com/15af5c52502c2921a759b9a72dea76aa70bac14d/third_party/WebKit/Source/core/editing/ime/InputMethodControllerTest.cpp
,
Jan 23 2018
Will be fixed in Chrome 66, targeted for release around April 17.
,
Jan 25 2018
,
May 4 2018
Tested on Chrome 66.0.3359.139. Issue is solved for Chinese and Japanese. Issue still reproducible for Korean, though. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Dec 1 2017