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.

The breakage

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 milliseconds).

The explanation

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-local input, the string is normalized into a standard form. [In normalized datetime strings] the time portion of the string is as short as possible. This is done by leaving out the seconds component if its value is :00.

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).

The fix

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 details).

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 2020-09-20T12:34:00.000 to 2020-09-20T12:34:56.789.

Conclusion

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.

FAQ

Updated: March 5, 2024

The first high-severity CVE since AngularJS End of Life has been officially reported. For AngularJS Never-Ending Support (formerly XLTS) clients, we found this CVE last year and issued a fix immediately. For all others, as Google’s official AngularJS long-term support partner, we encourage you to either:

1. Migrate off of AngularJS, or
2. Contact HeroDevs about how you can keep your AngularJS environment secure, compliant, and compatible indefinitely.