Selection dragging *does* fire touchstart/move/end on Safari, but doesn't on Chrome Android. See http://s.codepen.io/Krinkle/debug/JKYOpV .

Filed as a Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=617981

The only possible solution is therefore to ensure that the context menu doesn't interfere with the position of the surface.

Then this would presumably be automatically fixed via T96289: Fix the jump when opening the mobile context.

Shall we pull this on the board to work on @matmarex

I am moving this to stalled due to @matmarex commented in T221328 that:

Problem: When the cursor is placed inside a link annotation (or similar), the editor's context menu under the toolbar opens, and to make space for it, the editing area moves down. If this happens accidentally while the user is trying to precisely place the cursor by dragging it, the cursor may end up in the wrong place, the interaction to place it may be reset, and other visual glitches may occur.

Solution: This will be resolved by the proposed context menu redesign (also known as edit cards: T221247), which among other changes moves the context menu to the bottom of the window. We also considered a more immediate solution to avoid moving the editing area, but it proves surprisingly difficult to do while also avoiding new visual glitches and results in new poor interaction patterns when the context menu covers the editing area, and so we decided to wait for the context menu redesign.

As we have deployed the new edit cards to bn/he/fa we can just QA them on those wikis?