Chrome Version: 63.0.3220.0
OS: Android

What steps will reproduce the problem?
(1) Load the attached file (sample_minimized.html) onto a DCHECK-enabled Android device and open it in Chrome
(2) Long press and hit "select all"
(3) Type some text using the Swype keyboard

This DCHECK gets hit:
[FATAL:PlainTextRange.h(54)] Check failed: IsNotNull() in InputMethodController::SetComposition

right here when InputMethodController::SetComposition() tries to call AddImeTextSpans():
https://chromium.googlesource.com/chromium/src/+/703c6b6cf1bcd212168721e72bc79b4afacb370e/third_party/WebKit/Source/core/editing/InputMethodController.cpp#747

The fix might just be to check if the PlainTextRange is valid before trying to call AddImeTextSpans(). However, I think the root of the issue is that InsertIncrementalTextCommand is behaving oddly.

If I force a non-incremental text replacement (e.g. by making NeedsIncrementalInsertion() in InputMethodController.cpp return false), the bug does not occur, and all characters I type go inside the <a> element. However, with an incremental text insertion, the first character goes inside the <a> (assume I'm trying to type "Hello"):

<a>H</a>

So right now the composition is on "H". Then when I type the second character ("e"), Swype tries to replace the composition range with "He". This triggers an incremental text insert. InsertIncrementalTextCommand figures out we only need to insert the the "e" and sets the "ending selection" for the edit command (basically, the text that's going to be replaced) as a caret selection right after the "H":

<a>H|</a>

Now InsertTextCommand::DoApply() comes along and starts trying to insert the "e" (the incremental update computed by InsertIncrementalTextCommand). This goes fine until we run start_position (the start of the "ending selection") through PositionAvoidingSpecialElementBoundary():
https://chromium.googlesource.com/chromium/src/+/be35f28174767a1cd71f3614e1f3ec6ce4e1f0e8/third_party/WebKit/Source/core/editing/commands/InsertTextCommand.cpp#231

This moves the start position to be immediately *after* the <a> element.

The description of this method is "Operations use this function to avoid inserting content into an anchor when at the start or the end of that anchor, as in NSTextView." So I think we have two problems here:

1. This means the behavior of InsertIncrementalTextCommand is different from the behavior of InsertTextCommand in this situation (the first character goes in the <a> element, and all subsequent characters go outside, which I don't think is intended).

2. After the text is inserted *outside* the <a> element, the composition range now spans multiple text nodes, and in particular, is no longer contained in the <a> element we're expecting it to be contained in when we create the PlainTextRange to pass to AddImeTextSpans(). So I think that's why we're hitting an error there.
 

Deleted: sample_minimized.html 414 bytes

sample_minimized.html 414 bytes View Download