I guess this may be the same issue as in T203555.

So... it looks like there are no touch events when using the native selection handles. Thanks mobile web!

The best solution I can see is to use a fixed timeout[1], and fire a custom "selectionend" event if the selection hasn't changed for Xms. We could also fire this is the user starts to type, or tries to make a programmatic change (to ensure the new text appears in the right place).

1. https://stackoverflow.com/questions/15076173/end-of-text-selection-event

I started implementing the timeout solution, but there is another more serious issue. Even without any JS we can drag a selection across a CE=false nodes, the cursor just disappears. The only way around that would be to make all focusable nodes ce=true (temporarily?) but that sounds pretty drastic...

Maybe we should experiment to see whether we can get anywhere using newer features now fairly reliably available on Chrome mobile, e.g. shadow DOM.

I filed an upstream bug about the dragging across ce=false: https://bugs.chromium.org/p/chromium/issues/detail?id=894003

So it looks like you can do this with some weird CSS:

<p contenteditable=true>
  foo
  <span style="display: inline-block; position: relative; width: 25px; height: 15px;">
    <span style="position: absolute; display: block; user-select: none; z-index: -1;" contenteditable="false">bar</span>
  </span>
  baz
</p>

The absolutely positioned span is not part of the cursor flow, so the cursor never gets put in the ce=false.

The downside is that we have to fix the dimensions of the focusable (calculating them will be a performance hit), and we can't have focusables that wrap over two lines, because they are now display:inline-block. We could restrict this to smaller focusables as you are unlikely to want to drag a cursor across a larger one.

See also T136840

Since T214976 I'm am very wary of using user-select:none due to the effects in Firefox.

In T204387 @matmarex shared: This is a browser bug to which we haven't found an acceptable workaround, and may never.

For that reason, I recommend deprioritizing this task. It may not be worth the engineering effort and I don't know that this is an immediate blocker for our feature work.

Copying @marcella and @Esanders to weigh in. @ppelberg deferring to you on what to do with this ticket, the options are:

• Decline the ticket

• Move it to the Freezer

Moving this to the Freezer. Thanks for synthesizing the conversation, @JTannerWMF.