Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

input[time] renders with miliseconds in Firefox #16510

Closed
piotr-dobrogost opened this issue Mar 26, 2018 · 13 comments · Fixed by #16584
Closed

input[time] renders with miliseconds in Firefox #16510

piotr-dobrogost opened this issue Mar 26, 2018 · 13 comments · Fixed by #16584

Comments

@piotr-dobrogost
Copy link

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.

@frederikprijck
Copy link
Contributor

frederikprijck commented 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
Copy link
Author

piotr-dobrogost commented 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
Copy link
Contributor

If we remove milliseconds, firefox would still show seconds, even if they are 0.

@piotr-dobrogost
Copy link
Author

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 step attribute:

It takes an integer value that equates to the number of seconds you want to increment by; the default value is 60 seconds, or one minute. If you specify a value of less than 60 seconds (1 minute), the time input will show a seconds input area alongside the hours and minutes.

However this would still be a welcome improvement to the current situation.
Theoretically AngularJS could go as far as taking into consideration step attribute 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
Copy link
Contributor

frederikprijck commented 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 step attribute.

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
Copy link
Author

piotr-dobrogost commented Mar 27, 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.

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 step attribute as described earlier.

@Narretz
Copy link
Contributor

Narretz commented 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
Copy link
Member

gkalpak commented Apr 4, 2018

FWIW, according to the spec:

A time consists of a specific time with no time-zone information, consisting of an hour, a minute, a second, and a fraction of a second.
A string is a valid time string [...] if it consists of the following components in the given order:

  • [...]
  • If second is not an integer, or optionally if second is an integer:
    • A U+002E FULL STOP character (.)
    • One, two, or three ASCII digits, representing the fractional part of second

@frederikprijck
Copy link
Contributor

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
Copy link

spyro2000 commented 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
Copy link

We are running into the same issue. Any ideas or workarounds on this?

@Narretz
Copy link
Contributor

Narretz commented 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
Copy link
Contributor

Narretz commented Apr 23, 2018

Very rough example for the formatter: https://plnkr.co/edit/zI8Ncmyq6MO4D0Q1uvwQ?p=preview

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants