Repeating DOM (input[type=file] has a ~readonly value, causing crashes)

[rbt]

On submission of the form with a file selected, the DOM repeats. I was attempting to make a progress bar for a file upload when this appeared.

Seems to be broken in both 1.1.3 and Next in both FireFox and Chrome.

The main issue seems to be the round-trip of e.target.value for a file selection box. I've run out of brainpower to simplify this further but it almost certainly could be.

Order of the elements also seems to matter. Putting new material (version string in this case) after the form doesn't seem to cause the repeat.

https://codepen.io/rbt123/pen/WEPdby

[dead-claudia]

After toying around, I'm finding weirder things than even that... (pen, as minimal as I can get it)

• No wrapper element is required at all for any of them
• It can easily be reproduced with m.render directly
• The duplicated element need not be of any particular type; even a string works
• The duplicated element must not be rendered on the first pass.
• For some reason, I can't reproduce it with anything other than an input[type=file].
• The onchange event listener must be a Mithril-known one, but it need not re-render on click.
• The input[type=file] needs to change first, and the value "set" to whatever the new file is. (Mithril avoids setting the value when it's equal, so the spec'd error never happens.)
• The onchange listener must not update the state if it re-renders.
• The button click must update the state and re-render.

Super odd...

[pygy]

I moved it to flems for toying around with Mithril itself, and I get this error every first time I click the button after picking a file (look at the real console, flems only shows the last one that's been thrown):

InvalidStateError: Failed to set the 'value' property on 'HTMLInputElement': This input element accepts a filename, which may only be programmatically set to the empty string.

Not sure how that error ends up confusing m.render(), but it does.

Do we consider that a user error (value should not be set programmatically), or do we add it to the list of input.value exceptions?

Edit: reduced even more. onchange is a red herring...

Edit2: @rbt you can delete line 79 (inputOptions['value'] = view.fileValue;), it will solve your issue AFAICT. You need to make sure that the input[type=file] is preserved on diff (it is in your pen).

Edi3: m.render crashes before it swaps the root.vnodes field. As a consequence, the diff always starts with the initial vnode tree as old, and always adds the string to the DOM.

[dead-claudia]

@pygy Good spot! (I totally overlooked that part...)

Do we consider that a user error (value should not be set programmatically), or do we add it to the list of input.value exceptions?

I'd add this as another exception, provided it's the same string. If it's different, it's a user error, but if it's still the same string, we should accept it, so it still works with the common two-way binding pattern:

m("input[type=file]", {
    value: this.value(),
    onchange: m.withAttr("value", this.value)
})

[pygy]

We'd also need to special case the empty string (to reset the value)...

[rbt]

@pygy: Yep. Prior to submitting the ticket I changed my code to check the field type and skip setting the value for "file" fields. It does indeed solve the issue.

For a Mithril fix, I'd be perfectly happy if it threw an error.

[dead-claudia]

Still repros in mithril@next

[dead-claudia]

Not a blocker for v2, but it's something I want to get fixed soon.

[dead-claudia]

The root cause is a lot more subtle than it looks: Mithril doesn't know how to deal with errors during rendering at all, much less errors from DOM manipulations. It stems from input.value's setter throws for <input type=file> when it's not set to the empty string, but you can reproduce it with just components and normal (non-throwing) DOM nodes.

This is blocked on #2273.