Change to datetime-local input in Firefox v93
One of the aims of the XLTS for AngularJS product is ensuring that applications will continue to work on the latest versions of major web browsers. At XLTS.dev, we do our best to minimize the impact of potential issues on our users. In this case, it means identifying and addressing any potential breaking change caused by a new browser version before it affects our customers' users.
In order to identify issues with new browser versions as early as possible, we regularly run automated tests against the beta and dev versions of major browsers.
A few days ago, our tests started failing against Firefox v93. At that time, v93 was the dev version of Firefox. Currently, it is in beta and will be released as stable on October 5th, according to the Firefox release calendar.
The failures were related to how Firefox v93 formats the values of
datetime-local inputs. More
specifically, the test assertions were expecting a string value in the format
2021-09-20T12:34:00.000, but the actual
value was in the format
2021-09-20T12:34 (i.e. without the trailing zeros corresponding to seconds and
After some digging, it turned out that Firefox v93 started following the HTML specification more closely by omitting the seconds/milliseconds if they are all zeros.
According to MDN:
When you set the value of a
datetime-localinput, the string is normalized into a standard form. [In normalized
datetimestrings] the time portion of the string is as short as possible. This is done by leaving out the seconds component if its value is
If you are interested in the technical details, the HTML specification does indeed mention that "if and only if the value of the element is a valid local date and time string, then it must be set to a valid normalized local date and time string", where valid normalized local date and time string is further defined as consisting of:
- A valid date string representing the date.
- A U+0054 LATIN CAPITAL LETTER T character (T).
- A valid time string representing the time, expressed as the shortest possible string for the given time (e.g. omitting the seconds component entirely if the given time is zero seconds past the minute).
In this case, this is not an issue in the AngularJS source code, but in our test assertions. AngularJS can already cope
correctly with a
datetime value missing the seconds/milliseconds part and also allows specifying how you want the
values formatted in the view (see the
input[datetime-local] API docs for more
So, here the fix was just a matter of updating the test assertions to avoid the problem. Note that other browsers
(including the current stable version of Firefox) still include zero seconds/milliseconds in the string value. In order
to keep our tests the same for all browsers/versions, we updated the values used in tests to ensure they have non-zero
values for seconds and milliseconds. For example, changing input value
The XLTS.dev team keeps a close eye on the latest browser versions to ensure that any potential breaking changes are identified and addressed before affecting our customers' users. Recently, our monitoring infrastructure helped us catch and proactively investigate such a change in Firefox v93 (dev). In this particular case, we determined it does not cause an incompatibility with AngularJS, and it was just an issue with inadequate test assertions.