HTMLInputElement/HTMLTextAreaElement selectionchanged_event feature

[hamishwillee]

FF92 adds support for this spec change to selectionchange events in https://bugzilla.mozilla.org/show_bug.cgi?id=1648944

In summary,

• originally selectionchange_event (no cancel, no bubble) was fired on Document to indicate that the selection (essentially a "breaking point" node and optionally a range of nodes from that) had changed.
• The spec change lets you get events for a text selection. An event of the same name is fired on HTMLInputElement and HTMLInputElement. (i.e. <textarea> or <input>). This is not cancellable (as well) but can bubble. All these events are handled in GlobalEventHandlers.onselectionchange

What this does is add the event to HTMLInputElement and HTMLInputElement.

• I have put null for the other browsers. The spec change does not provide any indication either way and this thing seems to be out of date: https://docs.w3cub.com/dom_events/selectionchange
• I am using this as a test case: https://bugzilla.mozilla.org/show_bug.cgi?id=1648944#c0 - To me it looks like this is NOT implemented in chrome - essentially you get the old event if you select in on of the text elements (not bubblable).

Questions:

1. Does that make sense? Can you help me confirm that I can put false for webkit and chromium
2. Do I also need to add a subfeature in GlobalEventHandlers.onselectionchange to indicate the version in which the modified events changed?
3. Should Selection still be considered experimental?

Docs tracking: mdn/content#7755

[hamishwillee]

@ddbeck Howdy, can you please help me find someone to sanity check this one?

[ddbeck]

(Self-requested a review on this. Sorry for the wait, @hamishwillee.)

[ddbeck]

Answers to your questions, @hamishwillee. Thanks again for your patience on this.

1. Does that make sense? Can you help me confirm that I can put false for webkit and chromium

I tested this too and it looks right. I'd go ahead with false for Chrome etc. and the Safaris. 👍

2. Do I also need to add a subfeature in GlobalEventHandlers.onselectionchange to indicate the version in which the modified events changed?

I'm not 100% sure about this one. I don't think so, on the basis that the new features here cover that. But mixins are hard. @Elchi3 do you have a take on this?

3. Should Selection still be considered experimental?

No (not sure why it ever was, to be honest), but I'd say that ought to change in a separate PR.

[hamishwillee]

Thanks @ddbeck. I've updated the chromiums. This should be good to merge.

• If @Elchi3 responds to HTMLInputElement/HTMLTextAreaElement selectionchanged_event feature #12126 (comment) we can do those fixes as a post process.
• Selection being marked as not experimental is done in Selection API: change experimental to false #12332

[Elchi3]

1. Do I also need to add a subfeature in GlobalEventHandlers.onselectionchange to indicate the version in which the modified events changed?

I'm not 100% sure about this one. I don't think so, on the basis that the new features here cover that. But mixins are hard. @Elchi3 do you have a take on this?

We have #12290 on file to get rid of the last two mixins in BCD, so this one will get reorganized at some point. I'm fine with not updating it for the moment. Updating it can't hurt either, I guess. It depends on what is most useful to show on https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onselectionchange right now (that page should also be something else if we are decided what to do about this mixin).

[hamishwillee]

Thank @Elchi3. I won't document this in onselectionchange then. The implementation of onselectionchange itself has not changed - it is just that the events it catches may now from a different source (a HTML text element). Even though it might be useful for someone to know that here, technically any issues of compatibility are in the HTML elements (which I do document). I think I could argue it the other way too, but I vote this PR goes in "as is" and we revisit later if someone gets confused by this.

@ddbeck Upshot, this can be merged. Thanks!

[hamishwillee]

Thanks @ddbeck . Before I started this job I thought I was careful and meticulous :-(

[ddbeck]

Before I started this job I thought I was careful and meticulous

It turns out there's always more detail. 😅