Keeps a text-selection drag alive once the pointer leaves the field, by two mechanisms.
Driving the selection. From the press, each move re-reads the character under the pointer
(clamped into the field) and sets the selection itself. This is what makes the gesture behave the
same wherever the field is: the browser's own drag-extension resolves against the pointer's raw
position, which comes out wrong for a field inside a transformed ancestor — the in-grid cell editor
is placed by a transform: translate(…), and its selection tracked an x offset by that translate.
Asking for the offset explicitly goes through the same hit-test a click does, which is correct there.
Suspending the chrome's veto, for the presses the first mechanism does not take: a number input
(the selection API throws on one), a double/triple press (word and line granularity are the browser's),
or a shift-press (it extends an existing selection from its own far end). App chrome is
user-select: none — legitimately, since a drag over a toolbar
or the grid means something other than selecting their text — and a browser abandons a drag-selection
the moment the node under the pointer can't start one. That none states an intent that only holds
BETWEEN gestures, and CSS has no way to say "except while a drag is in flight", so the class says it
for exactly one. Nothing else becomes selectable in practice: a text control confines its own
selection, so the selection cannot leave the field.
Wire it to any field whose text is worth dragging across:
Keeps a text-selection drag alive once the pointer leaves the field, by two mechanisms.
Driving the selection. From the press, each move re-reads the character under the pointer (clamped into the field) and sets the selection itself. This is what makes the gesture behave the same wherever the field is: the browser's own drag-extension resolves against the pointer's raw position, which comes out wrong for a field inside a transformed ancestor — the in-grid cell editor is placed by a
transform: translate(…), and its selection tracked an x offset by that translate. Asking for the offset explicitly goes through the same hit-test a click does, which is correct there.Suspending the chrome's veto, for the presses the first mechanism does not take: a
numberinput (the selection API throws on one), a double/triple press (word and line granularity are the browser's), or a shift-press (it extends an existing selection from its own far end). App chrome isuser-select: none— legitimately, since a drag over a toolbar or the grid means something other than selecting their text — and a browser abandons a drag-selection the moment the node under the pointer can't start one. Thatnonestates an intent that only holds BETWEEN gestures, and CSS has no way to say "except while a drag is in flight", so the class says it for exactly one. Nothing else becomes selectable in practice: a text control confines its own selection, so the selection cannot leave the field.Wire it to any field whose text is worth dragging across: