Steps to reproduce the problem:
1. On Chromium on Android, go to data:text/html,<h1 contenteditable>w<span contenteditable=false>XY</span>z
2. Tap to put the cursor just after the 'z'
3. Using the pin, try to drag the cursor across the 'XY' to before the 'w'

What is the expected behavior?
The cursor moves sucessfully to before the 'w'.

What went wrong?
The cursor disappears completely (and the keyboard closes) 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 69.0.3497.100  Channel: stable
OS Version: 8.0.0
Flash Version: 

The problem only happens when the drag would put the cursor into the interior of the ce=false span. It doesn't happen:

1. If the span only contains one letter.
2. If the cursor is dragged really really quickly.
3. If the more text is added to the ce=false span so the 'z' wraps, and then the dragging is done directly upwards to the 'w' without crossing the ce=false span.

If you do this with an expanded selection instead, dragging one pin works fine so long as the other pin is not in a ce=false position. However individual words inside the ce=false span can be highlighted; that is, you can drag the expanded selection pin to highlight the FOO or the BAR in the following example:

<h1 contenteditable>w<span contenteditable=false>FOO BAR</span>z

When this happens, selectionchange is fired but the programmatic selection appears not to have changed.

I suspect the same thing is going on in both the expanded case and the collapsed one: 'disallowed' selections into the interior of the ce=false span are used somewhere in the code, but they get fixed up into an 'allowed' selection; and the trouble occurs if this fixup affects the anchor when you're moving the focus (or vice versa).