Internet Explorer + Ember 1.11 + {{input type="time"}} = Error: Invalid argument

[QuantumKing]

http://emberjs.jsbin.com/wikapibipa/1/edit?html,js,output

[rwjblue]

IE doesn't support <input type="date"> or <input type="time">, this is not an Ember issue.

References:

• http://caniuse.com/#feat=input-datetime
• https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/The_native_form_widgets#Date_and_time_picker

[QuantumKing]

@rwjblue This is an issue with Ember which previously didn't exist. IE reverts to a text input: http://emberjs.jsbin.com/fivecaqava/1/edit?html,js,output

[rwjblue]

Hmm. We are creating the DOM directly, and if the DOM being created is invalid on a given platform, I'm not sure what the path to fixing this would be.

I'll reopen this so that others can chime in, but it might not be fixable without mega-hacks...

@mixonic - I'd love your thoughts here...

[mixonic]

I apologize that I won't be able to look at this in detail before
Tuesday this coming week. Hard to get context with my limited resources
right now.

@QuantumKing if those inputs revert to a text box, how do you handle the
differing value formats coming off the input? I can type any text into
an text input, but a date or time input is very strict in its final
formatting. It sounds like regardless of what Ember does, you need to be
testing for this support and handling the return values differently if
you really want to support IE8.

I think there are several places in Ember that will explode if you use
an unsupported API. For example, if you use SVG in IE8, it will explode.
Creating an entire alternative rendering solution for SVG is not viable,
and I think creating browser-doesn't-support-this fallbacks that make
features appear to work but not actually behave the same is not a good
practice across the board.

TL;DR - If we make these input formats fallback to text they will not
cause crashes, but they will also not actually do what they are supposed
to do. This would be bad. It is merely the illusion of supporting IE8.
IMO, if you are supporting IE8 you need to really support it and handle
these cases.

On Sun, Feb 15, 2015, at 11:32 AM, Robert Jackson wrote:

Reopened #10458[1].

— Reply to this email directly or view it on GitHub[2].

Links:

1. Internet Explorer + Ember 1.11 + {{input type="time"}} = Error: Invalid argument #10458
2. Internet Explorer + Ember 1.11 + {{input type="time"}} = Error: Invalid argument #10458 (comment)

[QuantumKing]

@mixonic I'm using a time input in some preview screens of a mobile app. The mobile app code is reused on my website to create the preview. In this particular case there's no need to process the value of the input in the preview; it serves only as a visual demonstration. It would suck to have to maintain two separate codebases, or to include a conditional for IE on the mobile end...

[QuantumKing]

When inspecting the DOM tree, IE doesn't change the input to text:

[ehntoo]

Ran into this with IE9 and an input of type "email", where a degradation to "text" would be totally acceptable.

I would totally understand if this just gets marked as "won't fix", but it would be nice to get something other than a cryptic error like this:

SCRIPT87: Invalid argument. 
vendor.js, line 13438 character 7

In the meantime, I'm working around it by binding the input type to a computed property with some jQuery and http://www.paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/. This obviously won't work for things like the date/time input, though.

[MichaelVdheeren]

Same issue while using type="search". Failing jsbin: http://jsbin.com/wacihaqake/1/

[blimmer]

The fallback to text is a good start, but it doesn't allow us to use a polyfill for the special date type. Any chance that we could still insert the unknown type of input (e.g. date, search, etc.) in the case of a polyfill?

[mixonic]

@blimmer We cannot both fall back to text (by setting text) and set the original string. I suggest using a component that does something appropriate for all browsers.

[adamreisnz]

@mixonic Hi Matthew, this is still throwing an error for input type "tel" or "number" in IE9 it seems for Ember 1.11.3. Was this fixed in the 1.11.x branch? We are stuck with 1.11 and require IE9 support, so it would be nice to get this patched in that branch as well.

[rwjblue]

@adambuczynski - We do not backport non-security bug fixes to all affected versions. The fix for this was included from 1.12 forward.

[adamreisnz]

Cheers @rwjblue , thanks for the prompt reply. I will see if I can convince them to upgrade :)