input event is composed but change isn't

[mnoorenberghe]

In WICG/webcomponents#513 (comment) the idea of making the change event use composed: true was raised but I didn't see any further discussion on this and now I think there is inconsistency with respect to input vs. change events. The former uses composed: true whereas the latter does not yet they are very similar events, at least on text <input>s. I can't think of a reason why it would be desirable to have this discrepancy between the two. It seems like this was an unfortunate oversight unless this was discussed in a meeting and didn't make it back into the issue.

The MDN page for Event.composed currently states:

All UA-dispatched UI events are composed (click/touch/mouseover/copy/paste, etc.).

which I would consider incorrect given that many would consider the change event a UI event (lowercase e).

I assume the main reason why the change event isn't part of the UI Events specification is because it doesn't use a subclass of Event for historical compat. reasons but it seems like it should be treated like a UI event for most purposes.

Is there any chance of fixing this inconsistency at this point? It's not uncommon to use both events in a single library and this issue leads to incorrect behaviour with Shadow DOM.

[domenic]

Currently neither is composed, at least according to the spec. E.g. https://html.spec.whatwg.org/multipage/input.html#common-input-element-events says

When the user agent is to change an input element's value on behalf of the user (e.g. as part of a form prefilling feature), the user agent must queue an element task on the user interaction task source given the input element to first update the value accordingly, then fire an event named input at the input element, with the bubbles attribute initialized to true, then fire an event named change at the input element, with the bubbles attribute initialized to true.

and https://html.spec.whatwg.org/multipage/input.html#checkbox-state-(type=checkbox):input-activation-behavior says

2. Fire an event named input at the element with the bubbles attribute initialized to true.

3. Fire an event named change at the element with the bubbles attribute initialized to true.

neither of which mention the composed flag.

I can understand wanting them both to be composed, though. And it sounds like you've tested and at least some browsers have input as a composed event?

/cc @whatwg/components @mfreed7.

[smaug----]

Making input and change composed would reveal internals of Shadow DOM, and Shadow DOM wouldn't have ways to prevent light DOM to handle them before (capture phase) it handles them itself.

Unfortunately https://w3c.github.io/uievents/#event-type-input defines input and beforeinput as composed.
@garykac @masayuki-nakano

[mnoorenberghe]

Currently neither is composed, at least according to the spec.

@smaug---- is correct that it is defined as composed in the UI events spec. WICG/webcomponents#513 is where it was first suggested and I didn't see any disagreement there and then w3c/uievents#91 is what made the change with the comment "Reflect the conclusion of WICG/webcomponents#513."

I thought I also saw composed being set to true before dispatch in a spec but maybe I'm wrong about that and was looking at the UI Events PR.

And it sounds like you've tested and at least some browsers have input as a composed event?

Yes, input and beforeinput are composed: true in Gecko 77 (beforeinput is behind a pref), Chrome 81, and Safari 13.1, probably because of the UI Events spec.

[mnoorenberghe]

Code that assists users with filling forms will struggle on pages using Shadow DOM without composed input and change events and unfortunately IIUC FACE doesn't solve this as many pages don't even use <form> nowadays.

[domenic]

The UI events tables are not normative and should not be used for implementation. Unfortunately it sounds like maybe they were in some browsers.

[mnoorenberghe]

At this point is there any realistic chance UAs can change the input behaviour without breaking web compatibility? I suspect it's unlikely so perhaps we should specify it as composed: true now to match the three popular engines?

[rniwa]

The UI events tables are not normative and should not be used for implementation. Unfortunately it sounds like maybe they were in some browsers.

As far as I could tell, these behaviors were implemented before we refactored the spec to specify composed flag in each place. Previously, we determined based on the event type so it looks like input event was one of causalities during that transition. Given all browsers have been shipping this way for a while, it's probably hard to change this behavior now :(

[domenic]

I'll work on a pull request and tests to specify input as composed and change as non-composed, just to get the spec to match reality.

If any implementers are interested in changing this (e.g. @smaug---- seems in favor of making both non-composed) then please let us know. Otherwise I will assume that folks are reluctant to change, given the potential for compat problems. /cc @mfreed7

[annevk]

FWIW, I'm less concerned about the shadow tree leak here. Being able to observe that it contains something that would cause this event to be dispatched is fine and doesn't seem all that different from <input> itself to me. So aligning change seems somewhat reasonable in that light.

It does seem concerning that UI Events defines some of this as no upstreaming takes place. That is, UI Events defines InputEvent as event class, that's what implementations do, but that's not what the standard that dispatches these events defines. It would probably be better to remove this event from UI Events completely unless there's a dispatch site that's not covered by HTML? (This might also go for beforeinput.) w3c/uievents#275

[domenic]

We discussed this is in the triage meeting (#6739) and came to the conclusion the spec should stay as-is, and is somewhat justifiable, although in this case it's a bit strange.

In general, only very special events should be composed. Those are the events reflecting "direct user actions", where the user is communicating something interesting "to the page as a whole" in some sense. So for example, a click does indeed have a specific element that it targets, but it's a user interaction that the whole page should get notified of: i.e., it should compose past the shadow DOM boundaries. Stated another way, a component that uses a shadow tree should not be able to "trap" the event and prevent the rest of the page from ever seeing it.

On the other hand, events like change, submit, or load are not about a "direct user action" that affects the page as a whole. They are communicating something that changed internally to the event target in question. If that event target is inside a shadow tree, then the fact that it fired such an event is an internal detail of the component, which that component can choose to re-expose or not.

input falls into a somewhat gray area. It's not as clearly a direct user action as something like click, auxclick, or keydown. (Especially when it is fired on something like a checkbox.) But it somewhat is. This is especially true in the case of text entry controls, where it's part of a sequence involving beforeinput, composition events, and key events. So we ended up making it composed at some point in the past. Maybe we shouldn't have done that for non-text-entry cases, but that would probably be weird in a different way.

Combined with the compat concerns about changing behavior where all browsers agree, we think input should stay composed.