video -> http://go/chrome-androidlogs1/7/801388

issue doesn't repro on: 60.0.3112.116 
but repro on: 63.0.3239.111

Ryan, issue is not happening on 61.0.3163.98 but happens on 62.0.3202.84  

This bisects to https://chromium.googlesource.com/chromium/src/+/d86709e2200264d5af2b79cad6d6ad80c4f70259. Assigning to yosin@.

I'm not quite sure how, but it seems this CL introduced a behavioral regression.

The bug can be reproduced in Chrome without building WebView as follows:

1. Navigate to data:text/html,<div contenteditable> in Chrome for Android
2. Type some letters into the editable div (don't type a space)
3. Using the "Remote Devices" feature in the Chrome developer tools, run "document.execCommand('bold')
4. Type some more letters. They should be bold, but they're not on builds after this change.

This can almost certainly be reproduced in desktop IMEs as well.

(I tested using Gboard)

Mark Available since I don't have time to work.
rlanday@, could you take over? 

I'm not sure why my patch mentioned in #c7 causes this. The patch in question
just changed way to pass "Close Tying" option.


For #c7, I could not reproduce on desktop IME since loosing focus during
composition finishing composition.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d2e83f778ee04311b18b6a5ee5f5f5786d6d51ea

commit d2e83f778ee04311b18b6a5ee5f5f5786d6d51ea
Author: Ryan Landay <rlanday@chromium.org>
Date: Thu Jan 18 02:52:04 2018

Fix bug applying text formatting with open IME composition

In r489705, we changed a piece of code in
InputMethodController::SelectComposition() from:

GetFrame().Selection().SetSelection(
    SelectionInDOMTree::Builder().SetBaseAndExtent(range).Build(), 0);

to

GetFrame().Selection().SetSelection(
    SelectionInDOMTree::Builder().SetBaseAndExtent(range).Build());

This is not correct, because calling FrameSelection::SetSelection() with no
options param is not the same as calling it with no options:

void FrameSelection::SetSelection(const SelectionInDOMTree& selection) {
  SetSelection(selection, SetSelectionOptions::Builder()
                              .SetShouldCloseTyping(true)
                              .SetShouldClearTypingStyle(true)
                              .Build());
}

The fix is to explicitly pass SetSelectionOptions() to SetSelection(),
which does have the same behavior as the old code that passed 0.

I've filed  https://crbug.com/803278  to clean up SetSelection() to not set
these flags, since this behavior seems to be a potential source of
additional bugs.

Bug:  801388 ,802916
Change-Id: I84ae2f0a19839da2b9d42cd589325c3ee098ae00
Reviewed-on: https://chromium-review.googlesource.com/871184
Commit-Queue: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530030}
[modify] https://crrev.com/d2e83f778ee04311b18b6a5ee5f5f5786d6d51ea/third_party/WebKit/LayoutTests/fast/events/inputevents/inputevent-ime.html
[modify] https://crrev.com/d2e83f778ee04311b18b6a5ee5f5f5786d6d51ea/third_party/WebKit/Source/core/editing/ime/InputMethodController.cpp
[modify] https://crrev.com/d2e83f778ee04311b18b6a5ee5f5f5786d6d51ea/third_party/WebKit/Source/core/editing/ime/InputMethodControllerTest.cpp