applyFacts error with date type input and IE

[bigardone]

Hi!
I'm using Elm 0.18 in a new project I'm working on, and while testing it on IE11 and IE10, the application doesn't run due to a javascript error. I'm not really sure if this is the correct repository where to place this issue, but it's in the applyFacts function. To test it I'm using a multi-browser testing service, so I'm only able to take screenshots, but I hope it helps.
This is the error it throws:

It works on any other regular browser, so I guess it might be something related to IE and <input type="date" /> that I'm using. Does it make any sense?
Thanks in advance :)

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[jfornoff]

Encountered this as well, IE 11.0.09600, only with input[type="date"]

[jfornoff]

Encountered this as well, IE 11.0.09600, only with input[type="date"]

[mrozbarry]

I can confirm, and there is a reasonable fix.

In IE 11, if I do:

var e = document.createElement("input")
e.type = "date"

The browser throws an exception, but if I set it using element.setAttribute, it does not throw an exception, but does gracefully fallback to type="text":

var e = document.createElement("input")
e.setAttribute("type", "date")

Is there a reason that virtual dom would use element[key] = value over element.setAttribute(key, value)?

[mrozbarry]

I can confirm, and there is a reasonable fix.

In IE 11, if I do:

var e = document.createElement("input")
e.type = "date"

The browser throws an exception, but if I set it using element.setAttribute, it does not throw an exception, but does gracefully fallback to type="text":

var e = document.createElement("input")
e.setAttribute("type", "date")

Is there a reason that virtual dom would use element[key] = value over element.setAttribute(key, value)?

[peteygao]

This also plagues IE9, when using type_ "range". I imagine this issue occur whenever a type that's not supported by the IE version in question is set (range works in IE10, as an example, and thus will not throw this error for my particular use-case).

Thanks for that tip @mrozbarry, I'm going to make that patch locally to see if that resolves the problem for my use-case and report back.

[peteygao]

This also plagues IE9, when using type_ "range". I imagine this issue occur whenever a type that's not supported by the IE version in question is set (range works in IE10, as an example, and thus will not throw this error for my particular use-case).

Thanks for that tip @mrozbarry, I'm going to make that patch locally to see if that resolves the problem for my use-case and report back.

[peteygao]

Seems like there's a lot of issues with using setAttribute, chief among them the fact that you must use getAttribute to fetch them (which breaks the current VirtualDom implementation--I made the patch that @mrozbarry mentioned by swapping domNode[key] = value; with domNode.setAttribute(key, value); and the entire page broke even in non-IE browsers).

It also seems to be the recommended practice to set/retrieve properties (e.g. Element.propertyName = value) rather than interacting with HTML/DOM-level attributes (which is what the setAttribute/getAttribute setter/getter perform).

But here's the real kicker: the type attribute is WRITE-ONCE/READONLY in <= IE9 according to a third party IE bug tracker bug #237. According to the bug description:

In a DOM compliant browser, this is a piece of cake. However in IE (msdn article), the type attribute is read-only... except for a small window of time before you add an element to the DOM (e.g. if you are using createElement() )

Known Workarounds: None. If you copy all the information for a given node, into JS variables, then remove the existing element, and create a brand new one in its place, then you are set.

And low and behold, indeed the MSDN article mentions that the type attribute is write-once only:

The type property is read/write-once, but only when an input element is created with the createElement method and before it is added to the document.

Ugh 🤦🤦‍♂️...

[peteygao]

Seems like there's a lot of issues with using setAttribute, chief among them the fact that you must use getAttribute to fetch them (which breaks the current VirtualDom implementation--I made the patch that @mrozbarry mentioned by swapping domNode[key] = value; with domNode.setAttribute(key, value); and the entire page broke even in non-IE browsers).

It also seems to be the recommended practice to set/retrieve properties (e.g. Element.propertyName = value) rather than interacting with HTML/DOM-level attributes (which is what the setAttribute/getAttribute setter/getter perform).

But here's the real kicker: the type attribute is WRITE-ONCE/READONLY in <= IE9 according to a third party IE bug tracker bug #237. According to the bug description:

In a DOM compliant browser, this is a piece of cake. However in IE (msdn article), the type attribute is read-only... except for a small window of time before you add an element to the DOM (e.g. if you are using createElement() )

Known Workarounds: None. If you copy all the information for a given node, into JS variables, then remove the existing element, and create a brand new one in its place, then you are set.

And low and behold, indeed the MSDN article mentions that the type attribute is write-once only:

The type property is read/write-once, but only when an input element is created with the createElement method and before it is added to the document.

Ugh 🤦🤦‍♂️...

[evancz]

Tracking in #106 which is for any type_ issues.

Please continue discussion here if there is more information to share. The point of the meta issue is to do some organizing and editorializing that makes it easier to make progress on this sort of thing.

[evancz]

Tracking in #106 which is for any type_ issues.

Please continue discussion here if there is more information to share. The point of the meta issue is to do some organizing and editorializing that makes it easier to make progress on this sort of thing.