Having a matching `selectend` event?

[patrickhlauke]

A naive question, and there's probably a good reason why there isn't one already, but: would it make sense to also have a matching selectend event that fires once the user is done selecting something? Unless I'm misunderstanding, otherwise the process at the moment to work with the API is:

• wait for selectstart
• keep listening out for selectionchange events (which will keep firing as long as the user is still in the process of making the selection)
• have some kind of timer/debounce on the change listener, to try and work out when the user is done with selecting things (and/or listen out for mouseup, touchend, pointerup, etc to try and guess when the user finished), and then get the selected text with .getSelection()

[annevk]

When would we fire selectend? It's not clear to me the browser would be any better at this than the application.

[patrickhlauke]

that will depend on what the user agent does currently to determine that selection/highlighting is done - i'm assuming browsers know when that's happening? at least for mouse this should be the case.

for mouse: user presses left mouse button down on selectable content, selectstart is fired. user drags the mouse and highlights/selects content, selectionchange is fired. user lets go/releases left mouse button, they clearly ended their selection.

for touch, assume it's similar in terms of finger down, dragging/highlighting, then finger up (when UAs then often show contextual options/tooltips to copy etc). though i can see that then in cases where users are given controls to then manipulate the selection range may lead to further need for more selectstart/selectend for each operation where they drag the start/end markers.

keyboard (with caret type browsing) is probably the one case i can think of where it's indeed not unambiguous - but perhaps UAs could implement a heuristic that does the timer/debouncing internally and fires a selectend when IT believes selection is done?

[saschanaz]

user presses left mouse button down on selectable content, selectstart is fired.

It's not the mousedown itself causes selectstart, it changes the selection and thus selectstart happens. It sounds weird when selectstart is only about the selection and selectend suddenly cares about the input devices. (I mean, at least Gecko works that way)

[patrickhlauke]

if you're saying browsers currently don't know (internally) when a selection ended, then fair enough. i'm only describing what i observe from the outside here, not saying it should be tied to specific input devices

[saschanaz]

I think it still makes sense to have this event in web dev POV, and probably doable since Gecko does track the cause of selection changes anyway.

[johan]

Are you talking about cancelling / clearing a selection?

If not, feel free to think of every selection change as an end. If you select a bit with your mouse, let go of the mouse or tap, or shift key, and then grow or shrink it, whether with more keyboard shortcuts or dragging the selection handles at the start/end of the selection further out or in (maybe your OS / device doesn’t support that?), it’s still changing, even if you walked away for a cup of coffee in-between.

[patrickhlauke]

purely for mouse use, once you release the mouse button you can't change the selection further with the mouse (at least in Windows and macOS browsers). but yeah, I can see that you can at least expand it if you then switch to keyboard. fair enough, seems that the mouse case is then the odd one out/special case where there is some form of defined "end" (if you stick purely to mouse).

wonder if it's worth mentioning this in passing in the spec in some non-normative note, that just outlines the points above (i.e. there's not a defined "end" to a selection, as users can carry on expanding/manipulating their selection). otherwise, feel free to close this issue.