input event problems: FF behavior differs from Chromium and conflicts with what's documented on MDN

[ChALkeR]

Request type

• [ ] Please close this issue, I accidentally submitted it without adding any details
• [ ] New documentation
• [x] Correction or update

Details

On page Web/Events/input, MDN states that input event is implemented in Firefox, but actually that implementation differs from the standard.

It's documented in spec and MDN to have .composed === true set for input events, which looks to be true for Chrome 72 and Safari, but Firefox 65 has .composed === false for input events coming from a <select> element (and, possibly, some other elements).

Upd: This seems to affect <select> and <input type="checkbox"> at least, in Firefox 65. This does not seem to affect <input type="text"> elements — they emit input events with .composed set to true in Firefox 65.

Here is a testcase, could be also viewed on codepen:

<select>
  <option>change me</option>
  <option>select me</option>
</select>
<script>
  document.body.querySelector('select').oninput = e => {
    alert(`This should be true by spec: ${e.composed}`)
  }
</script>

Is something like this supposed to be mentioned in known issues on that MDN page, like other browser differences are?

Other browsers results (for <select> element):

• Chrome 72 on Linux, Android, and macOS report true.
• Safari on macOS reports true.
• Firefox 65 on Linux and macOS reports false, which seems to be invalid.
• Chrome 71 on macOS reports false, which also seems to be invalid.
• Firefox Nightly (67) reports false.

Corresponding spec links:

• https://w3c.github.io/uievents/#event-type-input
• https://www.w3.org/TR/uievents/#event-type-input
• https://dom.spec.whatwg.org/#event

MDN URL: https://developer.mozilla.org/en-US/docs/Web/Events/input

[ChALkeR]

Another problem on the same page:

The DOM input event fires synchronously when the value of an <input>, <select>, or <textarea> element has been altered.

But that is invalid.

Spec says:

The input event fires whenever the user has modified the data of the control. In all cases, the input event comes before the corresponding change event (if any).

Neither setting .value nor using .setAttribute("value", ...) triggers the input event -- only user input does.

So, s/has been altered/has been altered by user input/, I guess?

[ChALkeR]

This still holds, FF behavior differs from Chromium and conflicts with what's documented on MDN. This looks like "Partial support", I think.

[ChALkeR]

The input event fires when the value of an <input>, <select>, or <textarea> element has been changed.

This is also still wrong.

[wbamberg]

Yes, we had a rogue gitbot closing some issues that should have stayed open. It's a good reminder to fix some of these old issues though!

[vimirage]

I'm getting true from the linked codepen on Firefox from Android, Windows, and NetBSD. Can you confirm that this issue persists? And would we want to note this as an implementation note in BCD anyways?

[sideshowbarker]

I'm getting true from the linked codepen on Firefox from Android, Windows, and Linux (NetBSD).

Me too

Can you confirm that this issue persists?

@ChALkeR?

And would we want to note this as an implementation note in BCD anyways?

Yes — so I’ve now transferred it to the BCD issue tracker

[ChALkeR]

Ah, latest version indeed shows true.

This is false on 91.10.0esr though.

Not sure which exact version fixed it.

[queengooborg]

Looks like this was fixed in Firefox 95 -- I'll add a note regarding this!