Selection events for text controls

[ehsan]

The current spec doesn't explain what needs to happen for input and textarea elements when the selection inside them changes. Those selections are not associated with the Selection object for a Document, so we need to handle them somehow.

I think a nice way to extend the current spec to cover this case would be to dispatch selectstart and selectionchange to the input or textarea element itself when the selection inside them changes. The reason why the selectionchange event needs to be dispatched to the element and not the Document is that the web page would otherwise be unable to detect which selection has changed.

[ehsan]

ping?

[rniwa]

Sorry for the delayed response. That makes sense to me given other events on textarea/input. An alternative is to add a property on selectionchange/selectstart events that specify which input/texarea it originated from.

[ehsan]

An alternative is to add a property on slectionchange/selectstart events that specify which input/texarea it originated from.

I really preferred if we didn't do that, since that would make these events different than the other ones for input/textarea, and the selection APIs for those elements are already different from the global selection API.

(BTW I think this is the only spec issue we're waiting on before we can ship this API in Gecko...)

[ehsan]

(BTW I think this is the only spec issue we're waiting on before we can ship this API in Gecko...)

(#54 too)

[rniwa]

@foolip

I think we can close this issue by firing selectstart andselectionchange events on input and textarea elements.

[foolip]

@choniong @ojanvafai @dtapuska for Blink feedback on this issue.

[kojiishi]

@tkent-google @yosinch since this is a form spec issue.

I understand what's said, but it's also strange that selectionchange fires but window.getSelection() doesn't change. I don't know which is more prudent.

[tkent-google]

https://github.com/w3c/selection-api/issues/53#issue-101094502 looks good to me. I also think event.target should be input/textarea in such case.

[dtapuska]

Are you intending that selectionchange will bubble when fired at an input element?

[rniwa]

I understand what's said, but it's also strange that selectionchange fires but window.getSelection() doesn't change. I don't know which is more prudent.

That is already true when call setSelectionRange on the input element. The whole thing about selection in a text control is quite a bit messy but I think there are compelling use cases for wanting to know when the selection changes inside a input element or a textarea element, and firing selectionchange event in those elements DO address them.

[rniwa]

Here's a WebKit bug about this for example: https://bugs.webkit.org/show_bug.cgi?id=108043

[saschanaz]

Chrome currently triggers selectionchange on document for changes in text controls. Should the spec follow their behavior? Would changing the behavior cause a web compat issue?

[masayuki-nakano]

Fired the events only on Document node is reasonable for the performance. However, there is an issue. The event does not tell web apps which selection is changed, i.e., the original target is <input>, <textarea> or document's Selection. If Event.originalTarget were standardized, it'd be a good place to store the information. However, it's a Gecko-specific attribute. So, selection events should have a new interface?

[annevk]

I discussed that with @saschanaz and reportedly document.activeElement can be used. But yeah, a future revision could potentially change the event class to one that includes relatedTarget (I don't think we need originalTarget for this) so it's a bit more intuitive.

[masayuki-nakano]

I discussed that with @saschanaz and reportedly document.activeElement can be used.

In most cases, it must be correct. However, looks like the patches for Gecko, it's fired on any <input> and <textarea> elements if their selection is modified by JS or setting their value. Do other browsers fire the events in such cases too?

Anyway, it seems that the events should be fired only when the editable content is focused or should have something new attribute like originalTarget.

[saschanaz]

However, looks like the patches for Gecko, it's fired on any <input> and <textarea> elements if their selection is modified by JS or setting their value. Do other browsers fire the events in such cases too?

Blink and WebKit do not in such case. Edit: It does in Chrome 86/88.

BTW, one suggestion from @smaug---- was to fire on each <input> and <textarea> and bubble it up to document, but it seems that's not very web compatible idea?

[rniwa]

Another alternative is fire it on input & textarea then fire it again on its document. It's funky but maybe that's the most web compatible way to get to the interoperability? I think using relatedTarget would also work although it's not ideal.