Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test ivy JIT mode on IE #34279

Closed
wants to merge 3 commits into from
Closed

Conversation

gkalpak
Copy link
Member

@gkalpak gkalpak commented Dec 6, 2019

Builds on top of #34265 and #34277.

@googlebot
Copy link

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@mary-poppins
Copy link

You can preview 51c138e at https://pr34279-51c138e.ngbuilds.io/.

petebacondarwin and others added 2 commits December 6, 2019 18:34
Previously the JIT evaluated code for ivy localized strings included
backtick tagged template strings, which are not compatible with ES5
in legacy browsers such as IE 11.

Now the generated code is ES5 compatible.

Fixes angular#34246
The access of `__proto__` was introduced in 919f42f and from a quick
glance it is not clear why. Accessing `__proto__` is discouraged in
general ([according to MDN][1]), but most importantly it is not
supported by IE<11, resulting in an error.

This is a temporary work-around (falling back to the object itself when
`__proto__` is not defined), until we investigate and properly fix the
issue.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto

Fixes angular#34249
@gkalpak gkalpak changed the title TEST Test ivy JIT mode on IE Dec 6, 2019
@mary-poppins
Copy link

You can preview e4e5343 at https://pr34279-e4e5343.ngbuilds.io/.

crisbeto added a commit to crisbeto/angular that referenced this pull request Dec 8, 2019
Since we haven't been running the Ivy tests against IE for a while, we've accumulated some errors and test failures. These changes fix the issues which come from a handful of root causes:

**i18n instructions thrown off by sanitizer:**

While sanitizing on browsers that don't support the `template` element (pretty much only IE), we create an inert document and we insert content into it via `document.body.innerHTML = unsafeHTML`. The problem is that IE appears to parse the HTML passed to `innerHTML` differently, depending on whether the element has been inserted into a document or not. In particular, it seems to split some strings into multiple text nodes, which would've otherwise been a single node. This ended up throwing off some of the i18n code down the line and causing a handful of failures. I've worked around it by creating a new inert `body` element into which the HTML would be inserted.

**Proxies being used in DebugElement.classes:**

We're currently using proxies to pick up changes to element classes coming outside of Angular. Proxies aren't supported in IE and error is always thrown. I've reworked the tests where possible and skipped the rest with a TODO to come back and re-enable them once we have som kind of fallback.

**Inconsistent `typeof Node` value:**

We have a couple of cases where we use something like `typeof Node === 'function'` to figure out whether we're in a worker context. This works in most browsers, but IE returns `object` instead of `function`. I've updated all the usages to account for it.

**IE saving the attribute case:**

In `DebugElement.attributes` we return all of the attributes from the underlying DOM node. Most browsers change the attribute names to lower case, but IE preserves the case and since we use camel-cased attributes, the return value was inconsitent. I've changed it to always lower case the attribute names.

**Unable to get own function name:**

When we log DI errors we get the name of the provider via `SomeClass.name`. In IE functions that inherit from other functions don't have their own `name`, but they take the `name` from the lowest parent in the chain, before `Function`. I've added some changes to fall back to parsing out the function name from the function's string form.

**Different attribute order in innerHTML:**

We've got some tests that assert that the generate DOM looks correct. The problem is that IE changes the attribute order in `innerHTML` which caused the tests to fail. I've reworked the relevant tests not to assert directly against `innerHTML`.

**__proto__ not supported:**

IE doesn't support `__proto__`. I've added a fallback based on angular#34279.
crisbeto added a commit to crisbeto/angular that referenced this pull request Dec 8, 2019
Since we haven't been running the Ivy tests against IE for a while, we've accumulated some errors and test failures. These changes fix the issues which come from a handful of root causes:

**i18n instructions thrown off by sanitizer:**

While sanitizing on browsers that don't support the `template` element (pretty much only IE), we create an inert document and we insert content into it via `document.body.innerHTML = unsafeHTML`. The problem is that IE appears to parse the HTML passed to `innerHTML` differently, depending on whether the element has been inserted into a document or not. In particular, it seems to split some strings into multiple text nodes, which would've otherwise been a single node. This ended up throwing off some of the i18n code down the line and causing a handful of failures. I've worked around it by creating a new inert `body` element into which the HTML would be inserted.

**Proxies being used in DebugElement.classes:**

We're currently using proxies to pick up changes to element classes coming outside of Angular. Proxies aren't supported in IE and error is always thrown. I've reworked the tests where possible and skipped the rest with a TODO to come back and re-enable them once we have som kind of fallback.

**Inconsistent `typeof Node` value:**

We have a couple of cases where we use something like `typeof Node === 'function'` to figure out whether we're in a worker context. This works in most browsers, but IE returns `object` instead of `function`. I've updated all the usages to account for it.

**IE saving the attribute case:**

In `DebugElement.attributes` we return all of the attributes from the underlying DOM node. Most browsers change the attribute names to lower case, but IE preserves the case and since we use camel-cased attributes, the return value was inconsitent. I've changed it to always lower case the attribute names.

**Unable to get own function name:**

When we log DI errors we get the name of the provider via `SomeClass.name`. In IE functions that inherit from other functions don't have their own `name`, but they take the `name` from the lowest parent in the chain, before `Function`. I've added some changes to fall back to parsing out the function name from the function's string form.

**Different attribute order in innerHTML:**

We've got some tests that assert that the generate DOM looks correct. The problem is that IE changes the attribute order in `innerHTML` which caused the tests to fail. I've reworked the relevant tests not to assert directly against `innerHTML`.

**__proto__ not supported:**

IE doesn't support `__proto__`. I've added a fallback based on angular#34279.
crisbeto added a commit to crisbeto/angular that referenced this pull request Dec 8, 2019
Since we haven't been running the Ivy tests against IE for a while, we've accumulated some errors and test failures. These changes fix the issues which come from a handful of root causes:

**i18n instructions thrown off by sanitizer:**

While sanitizing on browsers that don't support the `template` element (pretty much only IE), we create an inert document and we insert content into it via `document.body.innerHTML = unsafeHTML`. The problem is that IE appears to parse the HTML passed to `innerHTML` differently, depending on whether the element has been inserted into a document or not. In particular, it seems to split some strings into multiple text nodes, which would've otherwise been a single node. This ended up throwing off some of the i18n code down the line and causing a handful of failures. I've worked around it by creating a new inert `body` element into which the HTML would be inserted.

**Proxies being used in DebugElement.classes:**

We're currently using proxies to pick up changes to element classes coming outside of Angular. Proxies aren't supported in IE and error is always thrown. I've reworked the tests where possible and skipped the rest with a TODO to come back and re-enable them once we have som kind of fallback.

**Inconsistent `typeof Node` value:**

We have a couple of cases where we use something like `typeof Node === 'function'` to figure out whether we're in a worker context. This works in most browsers, but IE returns `object` instead of `function`. I've updated all the usages to account for it.

**IE saving the attribute case:**

In `DebugElement.attributes` we return all of the attributes from the underlying DOM node. Most browsers change the attribute names to lower case, but IE preserves the case and since we use camel-cased attributes, the return value was inconsitent. I've changed it to always lower case the attribute names.

**Unable to get own function name:**

When we log DI errors we get the name of the provider via `SomeClass.name`. In IE functions that inherit from other functions don't have their own `name`, but they take the `name` from the lowest parent in the chain, before `Function`. I've added some changes to fall back to parsing out the function name from the function's string form.

**Different attribute order in innerHTML:**

We've got some tests that assert that the generate DOM looks correct. The problem is that IE changes the attribute order in `innerHTML` which caused the tests to fail. I've reworked the relevant tests not to assert directly against `innerHTML`.

**__proto__ not supported:**

IE doesn't support `__proto__`. I've added a fallback based on angular#34279.
crisbeto added a commit to crisbeto/angular that referenced this pull request Dec 8, 2019
Since we haven't been running the Ivy tests against IE for a while, we've accumulated some errors and test failures. These changes fix the issues which come from a handful of root causes:

**i18n instructions thrown off by sanitizer:**

While sanitizing on browsers that don't support the `template` element (pretty much only IE), we create an inert document and we insert content into it via `document.body.innerHTML = unsafeHTML`. The problem is that IE appears to parse the HTML passed to `innerHTML` differently, depending on whether the element has been inserted into a document or not. In particular, it seems to split some strings into multiple text nodes, which would've otherwise been a single node. This ended up throwing off some of the i18n code down the line and causing a handful of failures. I've worked around it by creating a new inert `body` element into which the HTML would be inserted.

**Proxies being used in DebugElement.classes:**

We're currently using proxies to pick up changes to element classes coming outside of Angular. Proxies aren't supported in IE and error is always thrown. I've reworked the tests where possible and skipped the rest with a TODO to come back and re-enable them once we have som kind of fallback.

**Inconsistent `typeof Node` value:**

We have a couple of cases where we use something like `typeof Node === 'function'` to figure out whether we're in a worker context. This works in most browsers, but IE returns `object` instead of `function`. I've updated all the usages to account for it.

**IE saving the attribute case:**

In `DebugElement.attributes` we return all of the attributes from the underlying DOM node. Most browsers change the attribute names to lower case, but IE preserves the case and since we use camel-cased attributes, the return value was inconsitent. I've changed it to always lower case the attribute names.

**Unable to get own function name:**

When we log DI errors we get the name of the provider via `SomeClass.name`. In IE functions that inherit from other functions don't have their own `name`, but they take the `name` from the lowest parent in the chain, before `Function`. I've added some changes to fall back to parsing out the function name from the function's string form.

**Different attribute order in innerHTML:**

We've got some tests that assert that the generate DOM looks correct. The problem is that IE changes the attribute order in `innerHTML` which caused the tests to fail. I've reworked the relevant tests not to assert directly against `innerHTML`.

**__proto__ not supported:**

IE doesn't support `__proto__`. I've added a fallback based on angular#34279.
crisbeto added a commit to crisbeto/angular that referenced this pull request Dec 8, 2019
Since we haven't been running the Ivy tests against IE for a while, we've accumulated some errors and test failures. These changes fix the issues which come from a handful of root causes:

**i18n instructions thrown off by sanitizer:**

While sanitizing on browsers that don't support the `template` element (pretty much only IE), we create an inert document and we insert content into it via `document.body.innerHTML = unsafeHTML`. The problem is that IE appears to parse the HTML passed to `innerHTML` differently, depending on whether the element has been inserted into a document or not. In particular, it seems to split some strings into multiple text nodes, which would've otherwise been a single node. This ended up throwing off some of the i18n code down the line and causing a handful of failures. I've worked around it by creating a new inert `body` element into which the HTML would be inserted.

**Proxies being used in DebugElement.classes:**

We're currently using proxies to pick up changes to element classes coming outside of Angular. Proxies aren't supported in IE and error is always thrown. I've reworked the tests where possible and skipped the rest with a TODO to come back and re-enable them once we have som kind of fallback.

**Inconsistent `typeof Node` value:**

We have a couple of cases where we use something like `typeof Node === 'function'` to figure out whether we're in a worker context. This works in most browsers, but IE returns `object` instead of `function`. I've updated all the usages to account for it.

**IE saving the attribute case:**

In `DebugElement.attributes` we return all of the attributes from the underlying DOM node. Most browsers change the attribute names to lower case, but IE preserves the case and since we use camel-cased attributes, the return value was inconsitent. I've changed it to always lower case the attribute names.

**Unable to get own function name:**

When we log DI errors we get the name of the provider via `SomeClass.name`. In IE functions that inherit from other functions don't have their own `name`, but they take the `name` from the lowest parent in the chain, before `Function`. I've added some changes to fall back to parsing out the function name from the function's string form.

**Different attribute order in innerHTML:**

We've got some tests that assert that the generate DOM looks correct. The problem is that IE changes the attribute order in `innerHTML` which caused the tests to fail. I've reworked the relevant tests not to assert directly against `innerHTML`.

**__proto__ not supported:**

IE doesn't support `__proto__`. I've added a fallback based on angular#34279.
crisbeto added a commit to crisbeto/angular that referenced this pull request Dec 8, 2019
Since we haven't been running the Ivy tests against IE for a while, we've accumulated some errors and test failures. These changes fix the issues which come from a handful of root causes:

**i18n instructions thrown off by sanitizer:**

While sanitizing on browsers that don't support the `template` element (pretty much only IE), we create an inert document and we insert content into it via `document.body.innerHTML = unsafeHTML`. The problem is that IE appears to parse the HTML passed to `innerHTML` differently, depending on whether the element has been inserted into a document or not. In particular, it seems to split some strings into multiple text nodes, which would've otherwise been a single node. This ended up throwing off some of the i18n code down the line and causing a handful of failures. I've worked around it by creating a new inert `body` element into which the HTML would be inserted.

**Inheriting injectable definition from parent class not working in IE10 JIT mode:**

The way definitions are added in JIT mode is through `Object.defineProperty`, but the problem is that in IE10 properties defined through `defineProperty` won't be inherited which means that inheriting injectable definitions no longer works. These changes add a workaround only for JIT mode where we define a fallback method for retrieving the definition. This isn't ideal, but it should only be required until v10 where we'll no longer support inheriting injectable definitions from undecorated classes.

**Inheritance issues in IE10:**

It looks like most of the inheritance functionality in Ivy wasn't working in JIT mode because we weren't accessing things correctly. These changes fix all of the cases.

**Proxies being used in DebugElement.classes:**

We're currently using proxies to pick up changes to element classes coming outside of Angular. Proxies aren't supported in IE and error is always thrown. I've reworked the tests where possible and skipped the rest with a TODO to come back and re-enable them once we have som kind of fallback.

**Inconsistent `typeof Node` value:**

We have a couple of cases where we use something like `typeof Node === 'function'` to figure out whether we're in a worker context. This works in most browsers, but IE returns `object` instead of `function`. I've updated all the usages to account for it.

**IE saving the attribute case:**

In `DebugElement.attributes` we return all of the attributes from the underlying DOM node. Most browsers change the attribute names to lower case, but IE preserves the case and since we use camel-cased attributes, the return value was inconsitent. I've changed it to always lower case the attribute names.

**Unable to get own function name:**

When we log DI errors we get the name of the provider via `SomeClass.name`. In IE functions that inherit from other functions don't have their own `name`, but they take the `name` from the lowest parent in the chain, before `Function`. I've added some changes to fall back to parsing out the function name from the function's string form.

**Different attribute order in innerHTML:**

We've got some tests that assert that the generate DOM looks correct. The problem is that IE changes the attribute order in `innerHTML` which caused the tests to fail. I've reworked the relevant tests not to assert directly against `innerHTML`.

**__proto__ not supported:**

IE doesn't support `__proto__`. I've added a fallback based on angular#34279.
crisbeto added a commit to crisbeto/angular that referenced this pull request Dec 8, 2019
Since we haven't been running the Ivy tests against IE for a while, we've accumulated some errors and test failures. These changes fix the issues which come from a handful of root causes:

**i18n instructions thrown off by sanitizer:**

While sanitizing on browsers that don't support the `template` element (pretty much only IE), we create an inert document and we insert content into it via `document.body.innerHTML = unsafeHTML`. The problem is that IE appears to parse the HTML passed to `innerHTML` differently, depending on whether the element has been inserted into a document or not. In particular, it seems to split some strings into multiple text nodes, which would've otherwise been a single node. This ended up throwing off some of the i18n code down the line and causing a handful of failures. I've worked around it by creating a new inert `body` element into which the HTML would be inserted.

**Inheriting injectable definition from parent class not working in IE10 JIT mode:**

The way definitions are added in JIT mode is through `Object.defineProperty`, but the problem is that in IE10 properties defined through `defineProperty` won't be inherited which means that inheriting injectable definitions no longer works. These changes add a workaround only for JIT mode where we define a fallback method for retrieving the definition. This isn't ideal, but it should only be required until v10 where we'll no longer support inheriting injectable definitions from undecorated classes.

**Inheritance issues in IE10:**

It looks like most of the inheritance functionality in Ivy wasn't working in JIT mode because we weren't accessing things correctly. These changes fix all of the cases.

**Proxies being used in DebugElement.classes:**

We're currently using proxies to pick up changes to element classes coming outside of Angular. Proxies aren't supported in IE and error is always thrown. I've reworked the tests where possible and skipped the rest with a TODO to come back and re-enable them once we have som kind of fallback.

**Inconsistent `typeof Node` value:**

We have a couple of cases where we use something like `typeof Node === 'function'` to figure out whether we're in a worker context. This works in most browsers, but IE returns `object` instead of `function`. I've updated all the usages to account for it.

**IE saving the attribute case:**

In `DebugElement.attributes` we return all of the attributes from the underlying DOM node. Most browsers change the attribute names to lower case, but IE preserves the case and since we use camel-cased attributes, the return value was inconsitent. I've changed it to always lower case the attribute names.

**Unable to get own function name:**

When we log DI errors we get the name of the provider via `SomeClass.name`. In IE functions that inherit from other functions don't have their own `name`, but they take the `name` from the lowest parent in the chain, before `Function`. I've added some changes to fall back to parsing out the function name from the function's string form.

**Different attribute order in innerHTML:**

We've got some tests that assert that the generate DOM looks correct. The problem is that IE changes the attribute order in `innerHTML` which caused the tests to fail. I've reworked the relevant tests not to assert directly against `innerHTML`.

**__proto__ not supported:**

IE doesn't support `__proto__`. I've added a fallback based on angular#34279.
@gkalpak
Copy link
Member Author

gkalpak commented Dec 9, 2019

Superceded by #34305.

@gkalpak gkalpak closed this Dec 9, 2019
@gkalpak gkalpak deleted the gcoghpr-pr34277 branch December 9, 2019 09:22
crisbeto added a commit to crisbeto/angular that referenced this pull request Dec 10, 2019
Since we haven't been running the Ivy tests against IE for a while, we've accumulated some errors and test failures. These changes fix the issues which come from a handful of root causes:

**i18n instructions thrown off by sanitizer:**

While sanitizing on browsers that don't support the `template` element (pretty much only IE), we create an inert document and we insert content into it via `document.body.innerHTML = unsafeHTML`. The problem is that IE appears to parse the HTML passed to `innerHTML` differently, depending on whether the element has been inserted into a document or not. In particular, it seems to split some strings into multiple text nodes, which would've otherwise been a single node. This ended up throwing off some of the i18n code down the line and causing a handful of failures. I've worked around it by creating a new inert `body` element into which the HTML would be inserted.

**Inheriting injectable definition from parent class not working in IE10 JIT mode:**

The way definitions are added in JIT mode is through `Object.defineProperty`, but the problem is that in IE10 properties defined through `defineProperty` won't be inherited which means that inheriting injectable definitions no longer works. These changes add a workaround only for JIT mode where we define a fallback method for retrieving the definition. This isn't ideal, but it should only be required until v10 where we'll no longer support inheriting injectable definitions from undecorated classes.

**Inheritance issues in IE10:**

It looks like most of the inheritance functionality in Ivy wasn't working in JIT mode because we weren't accessing things correctly. These changes fix all of the cases.

**Proxies being used in DebugElement.classes:**

We're currently using proxies to pick up changes to element classes coming outside of Angular. Proxies aren't supported in IE and error is always thrown. I've reworked the tests where possible and skipped the rest with a TODO to come back and re-enable them once we have som kind of fallback.

**Inconsistent `typeof Node` value:**

We have a couple of cases where we use something like `typeof Node === 'function'` to figure out whether we're in a worker context. This works in most browsers, but IE returns `object` instead of `function`. I've updated all the usages to account for it.

**IE saving the attribute case:**

In `DebugElement.attributes` we return all of the attributes from the underlying DOM node. Most browsers change the attribute names to lower case, but IE preserves the case and since we use camel-cased attributes, the return value was inconsitent. I've changed it to always lower case the attribute names.

**Unable to get own function name:**

When we log DI errors we get the name of the provider via `SomeClass.name`. In IE functions that inherit from other functions don't have their own `name`, but they take the `name` from the lowest parent in the chain, before `Function`. I've added some changes to fall back to parsing out the function name from the function's string form.

**Different attribute order in innerHTML:**

We've got some tests that assert that the generate DOM looks correct. The problem is that IE changes the attribute order in `innerHTML` which caused the tests to fail. I've reworked the relevant tests not to assert directly against `innerHTML`.

**__proto__ not supported:**

IE doesn't support `__proto__`. I've added a fallback based on angular#34279.
crisbeto added a commit to crisbeto/angular that referenced this pull request Dec 11, 2019
Since we haven't been running the Ivy tests against IE for a while, we've accumulated some errors and test failures. These changes fix the issues which come from a handful of root causes:

**i18n instructions thrown off by sanitizer:**

While sanitizing on browsers that don't support the `template` element (pretty much only IE), we create an inert document and we insert content into it via `document.body.innerHTML = unsafeHTML`. The problem is that IE appears to parse the HTML passed to `innerHTML` differently, depending on whether the element has been inserted into a document or not. In particular, it seems to split some strings into multiple text nodes, which would've otherwise been a single node. This ended up throwing off some of the i18n code down the line and causing a handful of failures. I've worked around it by creating a new inert `body` element into which the HTML would be inserted.

**Inheriting injectable definition from parent class not working in IE10 JIT mode:**

The way definitions are added in JIT mode is through `Object.defineProperty`, but the problem is that in IE10 properties defined through `defineProperty` won't be inherited which means that inheriting injectable definitions no longer works. These changes add a workaround only for JIT mode where we define a fallback method for retrieving the definition. This isn't ideal, but it should only be required until v10 where we'll no longer support inheriting injectable definitions from undecorated classes.

**Inheritance issues in IE10:**

It looks like most of the inheritance functionality in Ivy wasn't working in JIT mode because we weren't accessing things correctly. These changes fix all of the cases.

**Proxies being used in DebugElement.classes:**

We're currently using proxies to pick up changes to element classes coming outside of Angular. Proxies aren't supported in IE and error is always thrown. I've reworked the tests where possible and skipped the rest with a TODO to come back and re-enable them once we have som kind of fallback.

**Inconsistent `typeof Node` value:**

We have a couple of cases where we use something like `typeof Node === 'function'` to figure out whether we're in a worker context. This works in most browsers, but IE returns `object` instead of `function`. I've updated all the usages to account for it.

**IE saving the attribute case:**

In `DebugElement.attributes` we return all of the attributes from the underlying DOM node. Most browsers change the attribute names to lower case, but IE preserves the case and since we use camel-cased attributes, the return value was inconsitent. I've changed it to always lower case the attribute names.

**Unable to get own function name:**

When we log DI errors we get the name of the provider via `SomeClass.name`. In IE functions that inherit from other functions don't have their own `name`, but they take the `name` from the lowest parent in the chain, before `Function`. I've added some changes to fall back to parsing out the function name from the function's string form.

**Different attribute order in innerHTML:**

We've got some tests that assert that the generate DOM looks correct. The problem is that IE changes the attribute order in `innerHTML` which caused the tests to fail. I've reworked the relevant tests not to assert directly against `innerHTML`.

**__proto__ not supported:**

IE doesn't support `__proto__`. I've added a fallback based on angular#34279.
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants