bug(datepicker): cannot get property "remove" of undefined when opening the datepicker under Internet Explorer

[Wisdomb33r]

Reproduction

StackBlitz is not working under Internet Explorer, so I'll join here a minimal repro project (cli-generated, single appComponent).

datepicker-ie-undef-ref-repro-project.zip

Steps to reproduce :

• npm install
• npm run start-ie
• open http://localhost:4200 with Internet Explorer 11
• open the dev tools with F12, switch to "Console tab
• clic on the datepicker icon => the datepicker is opening properly, however is raising an error

Expected Behavior

Working datepicker without undefined ref error.

Actual Behavior

Datepicker is working properly, but with an exception raised while opening. Stacktrace :

Impossible d’obtenir la propriété « remove » d’une référence null ou non définie
TypeError: Impossible d’obtenir la propriété « remove » d’une référence null ou non définie
at value (xxxx:8444/frontend/main-es5.205b6fea08fdd5940c22.js:1:944089)
at value (xxxx:8444/frontend/main-es5.205b6fea08fdd5940c22.js:1:933067)
at Anonymous function (xxxx:8444/frontend/main-es5.205b6fea08fdd5940c22.js:1:301644)
at os (xxxx:8444/frontend/main-es5.205b6fea08fdd5940c22.js:1:301403)
at $a (xxxx:8444/frontend/main-es5.205b6fea08fdd5940c22.js:1:298437)
at Wa (xxxx:8444/frontend/main-es5.205b6fea08fdd5940c22.js:1:298097)
at template (xxxx:8444/frontend/main-es5.205b6fea08fdd5940c22.js:1:550837)
at Xr (xxxx:8444/frontend/main-es5.205b6fea08fdd5940c22.js:1:276492)
at Wr (xxxx:8444/frontend/main-es5.205b6fea08fdd5940c22.js:1:275179)
at yo (xxxx:8444/frontend/main-es5.205b6fea08fdd5940c22.js:1:281900)

Our project is using an Angular ErrorHandler which, among other things, is pushing the frontend errors stacktraces to backend. We currently have a stacktrace pushed for every datepicker usage, which is very annoying to detect other, more harmful frontend exceptions.

Environment

• Angular: 12.2.9
• CDK/Material: 12.2.9
• Browser(s): Internet Explorer 11
• Operating System (e.g. Windows, macOS, Ubuntu): Windows 10

[jelbourn]

Duplicate of angular/components#23736

[crisbeto]

@Wisdomb33r I just looked into it and the problem comes from the fact that there's a class binding on an svg element which IE doesn't support. You can uncomment this in your polyfills.ts to fix it:

/**
 * IE11 requires the following for NgClass support on SVG elements
 */
// import 'classlist.js';  // Run `npm install --save classlist.js`.

[Wisdomb33r]

@jelbourn @crisbeto Tested and confirming working with classlist.js polyfill.

I suggest adding this requirement in a way or another into the ng new and/or ng update process of the CLI. It's not a critical bug but as v12 is the very last version compatible with Internet Explorer, it would be nice to have the framework as easy to use and stable as possible for the companies unfortunately locked with Internet Explorer.

Thanks for the digging and solution, very helpful !

[crisbeto]

This is an issue on the CLI which dropped the polyfills related to IE. I'll reopen the issue and transfer it to their repo since it shouldn't have happened on the 12.x.x branch.

[alan-agius4]

The classlist.js polyfill was always on opt-in bases.

@crisbeto, did something in Material change that now requires this polyfill? If that's the case I suggest that during ng-add for @angular/material version 12, this polyfill is enabled and installed.

[alan-agius4]

Seeing angular/components#23736 it appears that certain IE 11 cleanups landed incorrectly in the patch branch.

It also appears that @jelbourn reverted this changes and are awaiting a new release. Therefore, this is truly a duplicate of angular/components#23736.

Closing since no further actions are needed.

[crisbeto]

@alan-agius4 I transferred this issue, because it isn't related to the accidental cleanup that @jelbourn was talking about. We haven't made any changes that would cause a classList.remove call to fail on an SVG element. My guess was that the CLI might've landed the migration that removes the IE polyfills in the 12.x.x branch, because the issue sounds like things used to work for @Wisdomb33r on an earlier version.

[alan-agius4]

@crisbeto, there wasn't any change regarding this and classlist.js as this always on opt-in bases. The main reason for this is that the CLI only enables polyfills which are needed by the framework. Neither the framework nor material depended on classlist.js since these didn't use NgClass on SVG elements.

Recently this changed however, as material became dependent on this polyfill because of this change which landed in 12.1.x. This sort of is a breaking change for existing v12 users and want to support IE 11 as they might not have classlist.js installed and enabled.

There are a number of things here that can be done;

1. Transfer the issue back in the components repo for visibility and do nothing else.
2. Enable the classlist.js polyfill for new users in v12
3. Add a migration to enable classlist.js polyfill in version 12 for existing users. That said, it's unlikely that existing users will run migrations in patch versions.
4. Revert the change or find an alternative which doesn't require classlist.js.

[crisbeto]

Thanks for tracking it down @alan-agius4. We reverted the change in the 12.2.x branch with angular/components#23786.

[alan-agius4]

@crisbeto, awesome, thanks for the update and quick turn around!