Polymer build --bundle --js-compile not working in ie11

[beonglee81]

Description

Using Polymer 2.0 and building with polymer --bundle --js-compile is not working in ie11... currently getting the following error

Dug around and saw that template.cloneNode(true) wasn't cloning the content property, possibly because it was DocumentFragment. Tried doing putting a workaround described in webcomponents/webcomponentsjs#362 but that also yields different errors..

Versions & Environment

• Polymer CLI:1.5.1
• node:v 6.2.0
• Operating System: MacOs 10.11.6

[justinfagnani]

@beonglee81 do you only get this error when bundling?

[beonglee81]

@justinfagnani yes only when bundling option is true. works fine if not.

[beonglee81]

I also noticed that the error doesn't show up if I use static get template() instead of <template> under dom-module... seems like something is off with template polyfill when bundling.

[justinfagnani]

@beonglee81 Assuming you're using web-components-loader, can you try webcomponents-lite and see if it fixes the problem?

Our guess is that the template polyfill hasn't run by the time that the component scripts run, and so template elements aren't set up correctly.

[beonglee81]

I tried both the web-components-loader and webcomponents-lite without any luck. Error still exists..

[zpv]

I am experiencing the exact same error.
Tried both webcomponents.js & webcomponents-lite.

Compiling using:

• macOS 10.12.6.
• polymer-cli version 1.5.2

[beonglee81]

@usergenic @justinfagnani Any updates or ETA? we're also planning to use Polymer 2.0 on a new project but won't be able to if ie11 is not supported..

[LarsDenBakker]

We are halfway through our Polymer 2 migration for a large application and running into what I think is this issue. We see it even when we run the polymer shop and the polymer starter kit.

We get an error 1/5 times we load the application, so it seems to be an async issue. The error is random in the form of 'Unable to get property XXX of undefined or null reference'.

From our debugging, it always happens on this line:

https://github.com/webcomponents/custom-elements/blob/master/src/CustomElementInternals.js#L252

We are in a deadlock now, we need to decide what to do. It would be great to get some official guidance on this.

[bicknellr]

@LarsDenBakker, that line doesn't actually have any property accesses so I'm a bit confused as to why that particular error would result from it. Do you happen to have a reduced test case that can reproduce this issue? Also, could you make sure you're breaking on all (including uncaught) errors? I think you might be seeing this error at this line because it's being thrown from somewhere further down the stack, in or below the element's constructor.

[LarsDenBakker]

Sorry I didn't explain that well enough. It does indeed happen inside the constructor, and then the error gets caught there. I've not been able to debug it further than that, IE11 is not very great at debugging. Will dig further.

The reduced test case for me is both the shop app and the polymer starter kit. I've played around with removing imports, and it somewhat seems to be related to the number of imports but I can't say for sure.

[nsmith22]

I am experiencing the same issue, very interested to get this resolved.

[justinfagnani]

Does anyone here have a minimal reproduction they can provide? Something with as few files and imports as possible?

[justinfagnani]

Adding @azakus as an assignee, as this looks like an interaction between bundling, the template polyfill and possibly how core boots up elements.

The problem is likely that the template polyfill hasn't upgraded main page templates by the time elements try to access their template's content.

A few solutions could be:

1. Any <template> wrapping element (like dom-module) to call HTMLTemplateElement.decorate
2. Developers add a HTMLTemplateElement.bootstrap(document) call after the polyfills load
3. The bundles injects that call

[dfreedm]

Should be fixed in webcomponentsjs v1.0.16

[dfreedm]

There was a very easy spot to make sure that HTMLTemplateElement polyfill runs before custom elements boot up in the webcomponentsjs bundle.

[justinfagnani]

@beonglee81 you said you're still seeing this issue. @azakus make a minimal reproduction that fails before webcomponentsjs v1.0.16 and passes with it: https://gist.github.com/azakus/b01dc558b53fef5b45c8c4aff0f37aa1

Since this works, your setup must have some different interaction causing the failure. Can you make a similar reproduction that still fails with webcomponentsjs v1.0.16?

[dfreedm]

webcomponentsjs v1.0.17

[mleonardallen]

@azakus @justinfagnani We no longer get the initial JavaScript error, but I'm not seeing it work with more than the bare bones example. Here, I've added a dom-if, and I'm seeing extra slashes added in the HTML.

Also see the HTML output in the browser - both Hello and World display when expected results is only one is displayed.

<link rel="import" href="../polymer/polymer-element.html">
<link rel="import" href="../polymer/lib/elements/dom-if.html">

<dom-module id="hello-world">
  <template>
    <style>
      :host {
        display: block;
      }
    </style>
    
    <template is="dom-if" if="[[foobar]]">
      <h2>Hello</h2>
    </template>
    <template is="dom-if" if="[[!foobar]]">
      <h2>World</h2>
    </template>
  </template>
  ...

[dfreedm]

@mleonardallen I've tried bundling a reconstruction of your code snippet, but I can't recreate what you are seeing: https://glitch.com/edit/#!/eight-drop?path=index.html:18:13

[mleonardallen]

@azakus are you using polymer serve?
https://glitch.com/edit/#!/eight-drop?path=package.json:1:0

We only see this issue when using

polymer build --bundle --js-compile

[dfreedm]

Yes, I tried using polymer build as well, but did not experience what you are seeing.

I would have put that on Glitch, but the pipeline is too big for Glitch's rather tiny allowed disk space.