Repository navigation
input[time] renders with miliseconds in Firefox #16510
Description
I'm submitting a ...
- [x ] bug report
Current behavior:
Setting value of model to which input[type="time"] directive is bounded to, to instance of Date makes control display miliseconds in Firefox.
Expected / new behavior:
Description at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time documents only optional seconds but not miliseconds. Input field of type input[type="time"] should not display miliseconds.
Minimal reproduction of the problem with instructions:
Plunker available at https://docs.angularjs.org/api/ng/input/input%5Btime%5D page.
AngularJS version: v1.6.10-build.25885+sha.c68b31c (current snapshot)
Browser: Firefox 59.0.1
Anything else:
This is similar to issue #10721 however not the same as now Firefox does support input[type="time"]. Probably both problems stem from Angular not formatting model's value properly when calculating input's value in case of Firefox.
Activity
frederikprijck commentedon Mar 26, 2018
I did some debugging to see what AngularJS is doing and what's being sent to the native controls.
It looks like this format behaves differently in firefox and chrome: https://jsfiddle.net/Labze1fg/2/
Chrome drops zeroes whereas firefox doesn't.
If we would modify the plunkr, provided through the AngularJS docs, to also contain none-zero milliseconds you'll see both chrome and firefox contain the milliseconds: https://plnkr.co/edit/WcfbJE3o7mwxmkdHzSte?p=preview
piotr-dobrogost commentedon Mar 26, 2018
@frederikprijck
Thanks for taking a look at this. Your finding is interesting. The question is what should the sane behavior be when on one side miliseconds are not meant to be displayed in this input and on the other side Angular gets value as Date object which always does include miliseconds? I think the correct behavior would be to always skip miliseconds when providing value to native control. This would also result in fixing wired behavior of Firefox here.
frederikprijck commentedon Mar 26, 2018
If we remove milliseconds, firefox would still show seconds, even if they are
0.piotr-dobrogost commentedon Mar 26, 2018
Well, this seems again not quite right as https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time suggests presentation of seconds input area depends on the value of
stepattribute:However this would still be a welcome improvement to the current situation.
Theoretically AngularJS could go as far as taking into consideration
stepattribute when calculating value for time input; when not specified or above 60 use "HH:mm" format, otherwise use "HH:mm:ss" format.In any case there is a question what to do with seconds and/or miliseconds which are not presented? Should they become 0 in the model's final value or should they be kept intact from initial value?
frederikprijck commentedon Mar 26, 2018
Well, if you look at the fiddle, you can see It's not using AngularJS. So removing the milliseconds will still show the seconds even if they are 0, unrelated to AngularJS.
I'm not sure there can be done a lot from the AngularJS side for a control that's not working as expected in a specific browser. AngularJS isn't meant to be the go-to library to fix incorrect behavior in a browser.
The only thing I'm wondering is why we are formatting the date using milliseconds knowing those aren't supposed to be supported in the input (not based on the MDN link, neither based on the spec, see https://html.spec.whatwg.org/multipage/input.html#time-state-(type%3Dtime) & https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-string )?
@gkalpak any idea ? This has been explicitly added in 4b83f6c
piotr-dobrogost commentedon Mar 27, 2018
True. That's why value for native input should be provided as a string which allows to skip miliseconds and seconds. Miliseconds should be skipped always and seconds according to
stepattribute as described earlier.Narretz commentedon Apr 4, 2018
@piotr-dobrogost what is your suggested course of action for this issue? e.g what changes should be made to fix this?
gkalpak commentedon Apr 4, 2018
FWIW, according to the spec:
frederikprijck commentedon Apr 4, 2018
If I get this correct, this means the firefox implementation isn't in-line with the specs (so is the MDN link provided above).
spyro2000 commentedon Apr 20, 2018
Having the same problem with Angular 1.6.9. Despite the step attribute (and in fact even if I set the ms of the provided date to 0) the input field is still displayed with ms (which is very confusing).
Not sure if this actually a bug in Firefox (which time input fields sucks in general IHMO, especially when compared to Chrome's implementation).
piller187 commentedon Apr 20, 2018
We are running into the same issue. Any ideas or workarounds on this?
Narretz commentedon Apr 23, 2018
I think the spec @gkalpak linked: https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-string only talks about valid time format strings, not the representation of these strings in the input[time]: https://html.spec.whatwg.org/multipage/input.html#time-state-(type=time)
I can't find anything in the spec about dropping milliseconds when they are 0 (in the input). Browser vendors have a lot of freedom here, which often leads to suboptimal cross-browser experience.
You could always create a custom formatter that removes the milliseconds if they are 00. Basic example:
I don't think we should do this in core, though, since other devs might expect the milliseconds to appear.
We also cannot detect if no milliseconds are set in the Date object (on construction), because Date doesn't discriminate between "0" and "not set".
Narretz commentedon Apr 23, 2018
Very rough example for the formatter: https://plnkr.co/edit/zI8Ncmyq6MO4D0Q1uvwQ?p=preview
feat(ngModelOptions): add `timeStripZeroSeconds` and `timeSecondsFormat`
feat(ngModelOptions): add `timeStripZeroSeconds` and `timeSecondsFormat`