Sorry, going back to "Type-Bug" to let the input team decide if this is a feature request or bug. Feature requests may not show up in triage searches.

rbyers@; I'm assigning this to you so you can comment on the interoperability of this with in the touch events spec space.

I do see equivalence of this with mousemoves being fired during text selection.

This is an interesting use case, thanks!  I definitely agree with the big picture that it should be possible to augment text selection behavior in JavaScript.  In general editing (and touch text selection in particular) is known to have a big problem with not being inline with the extensible web (https://github.com/extensibleweb/manifesto).

My initial reaction was to say: "sure, if Safari is doing this we should just match".  But I've spent some time playing with Safari and it's not quite so simple.

It looks like when you're dragging the carat around (the UI with the circular magnifying lense) you do indeed get touch events.  But if you double-tap on a word to select it and then try dragging one of those handles, you appear to get selectionchange without the touch events.  That's still a problem for you, right?

This design makes sense to me - for a gesture that starts by touching anywhere on the page, the page gets to see the entire event stream.  But if the user touches on a UI element (like a selection handle) that's floating over TOP of the page, then the entire event sequence is hidden from the page.  I think Chrome and Safari are consistent on this design point (while matching their host OS's difference in selection UX).

The other problem here is what should be done if the touch events are canceled.  If you call preventDefault on such a touchmove, should it prevent the handle from dragging?  That would probably be unacceptable from a performance perspective (would make handle dragging tied to the JS thread).  So maybe instead we could treat this similarly to scrolling: once dragging starts the touchmove events have cancelable=false.

There's some risk of double-handling behavior here (eg. user is trying to move a selection handle but a carousel is sliding under their finger in response to the touchmove events, making it impossible to correctly position the handle).  But that's a potential problem with scrolling today too and is generally addressed by cancelling the touchstart or first touchmove event.  To support passive touch listeners, we might also need to disable selection over elements where scrolling has been disabled with touch-action (or, ugh, worst-case add new touch-action keywords for controlling selection).

So this would basically be a model where selection dragging was the default action of the first touchmove.  The page would always get first crack at the events ("content not chrome" FTW!) and if canceled, the user couldn't drag the handle.  The problem with this is that for the cases where it's not the intended UX (eg. selectable text inside of a swipable carousel), there's no good way for the developer to give priority to selection (there's no API to indicate that the touch actually occurred over a handle).  I think that kills this idea :-(

I see two other options:

1) Fire touch events at the 'window' in this case.  I.e. the handle still occludes the HTML underneath, so touches can't actually hit any DOM elements.  But the conceptually still "bubble" up to the containing window which holds the handles.  These could probably be strictly uncancelable (though maybe it would also be fine to allow the app to prevent handle dragging if it was really listening on the window).

2) Stop trying to use touch events for this and instead extend the selection APIs.  Eg. maybe the selectionchange event should have an "inProgress" boolean on it which is true while a change is actively happening, and false on the last event in a sequence (which I guess might not actually change the selection at all).  Or there could just be a simple "selectionchangeend" event.

Thoughts?

I like 2) "inProgress"/"selectionchangeend" event proposal.  If we add it, we should also make it work properly during mouse selections (as a more portable alternative to listening to MouseUp).

Your uncancelable touch event idea 1) seems just too weird to me -- there is no analogy anywhere else in the platform, and I think it will also seem weird to web developers who will use editing-related events everywhere except for this one thing.

It should be "selectionchangeend", not "inProgress" property on "selectionchange", because of your note that at release time, it "might not actually change the selection at all".  It's too unnatural to send a selectionchange event when the selection didn't change.

Ok, let's track this as a feature request for a "selectionchangeend" event then.  yosin@, ojan@, dtapuska@, chongz@ any thoughts?

Let's keep our eyes out for other examples where developers want this in order to prioritize it properly.

Adding a selectionchangeend event seems totally reasonable to me. I don't see any downside aside from needing to do the work to spec and get cross vendor agreement.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot