UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2783.2 Safari/537.36

Example URL:
http://codepen.io/Bwrrp/pen/dXWmBp

Steps to reproduce the problem:
1. Go to http://codepen.io/Bwrrp/pen/dXWmBp
2. Click anywhere in the preview to select the div around "Inside selection" and "Lorem ipsum…" and cycle through different combinations of contenteditable="true" or contenteditable="false" on the three marked divs. An orange border indicates the contenteditable value "false", blue indicates "true".
3. See the selection disappear when the inner divs have opposite editability compared to the outer div.

What is the expected behavior?
Expected selection to render correctly in all combinations used in the codepen.

What went wrong?
When the start point of the selection is located between two elements with contenteditable value opposite to the surrounding element, the selection is not rendered as selection highlight, but as a normal cursor at its end point. Accessing the selection through the window.getSelection() API reveals it is not actually collapsed. This is illustrated in the codepen by displaying the HTML for the first selected element.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 53.0.2783.2  Channel: dev
OS Version: 
Flash Version: Shockwave Flash 22.0 r0

As a work-around, uncomment the div class="workaround". It seems that introducing an element without the contenteditable attribute next to the start point of the selection allows the selection to be visible in all combinations.

The selection renders as expected in all combinations in Firefox and Edge. This seems to trigger a different bug in Safari, as it silently refuses to set the selection in some combinations or even selects the workaround div instead.