Lit-html: Repeat inside a slotted element is not working correctly in firefox

[lucaelin]

First of all I'm not entirely sure if this bug is related to lit-html, lit-element or shady dom...
I notices some of my elements would disappear when using the repeat function inside another custom element that uses a slot. They disappear whenever a render event causes the repeat to execute a second time, but only in Firefox and only if the repeated element has an object property.
I've created a small demo of this at https://lucaelin.github.io/litbug/ (https://github.com/lucaelin/litbug)..
So to recap:

• only happens in Firefox and not in Chome (even with forced shady dom)

• the repeat must assign an object to a repeated elements property

• the repeat must happen inside another element that uses a slot

• something must trigger the parent to render a second time

When using my code to reproduce, you can see that I use rollup to bundle three elements and include them directly into the head of the index. Those three elements are my-element, my-slot and my-child.
my-element renders a my-slot element with several my-child elements in it.
The array (called array) used to repeat my-child has an object with a val key in it.
The Object is assigned to the obj property of my-child and my-child renders the given objects val property to its dom.

Another detail: When using map instead of repeat, the elements that are already in the dom when the first render happens are updated correctly. However if you add another object to the array the resulting additional my-child would not be rendered correctly.

I am confused :smile:

[ruphin]

From some preliminary investigation it looks like this is not caused by lit-html but an underlying problem with the webcomponents polyfill. I have a reproduction of this issue using lit-html directly, and I am working on a vanilla Web Components reproduction.

[ruphin]

I cannot reproduce the problem with a vanilla Web Components implementation.

There is indeed a broken interaction with lit-html and the webcomponentsjs polyfill when rendering into distributed Light DOM, I can reproduce this error on Firefox and Edge. Elements that are added after the initial render() by lit-html do not trigger the webcomponentsjs polyfill, and are never upgraded. From what I can tell, this only happens for slotted content.

The only difference between working and broken implementation is

this.shadowRoot.innerHTML = `
  <my-slot>
    ${this.array.map(() => `<my-child></my-child>`).join('')}
  </my-slot>`;

vs

render(html`
  <my-slot>
    ${this.array.map(() => html`<my-child></my-child>`)}
  </my-slot>`,
  this.shadowRoot);

I will look into what exactly causes the problem. Meanwhile I have created a minimal reproduction of the issue (based on the reproduction made by @lucaelin):
https://ruphin.github.io/litbug/

Relevant source: https://github.com/ruphin/litbug/blob/master/elements.js

[justinfagnani]

Thanks for reproduction @lucaelin and for looking into this @ruphin!

@ruphin would you like me to assign this to you?

cc @sorvell and @azakus for thoughts from the polyfill side.

[ruphin]

Yes, you can assign this issue to me.

It is still unclear to me if the fix should be handled from the polyfill side or by lit-html. I'll report to the polyfill folks if I find reason to believe the issue is on that side. I also still have to test if the problem occurs on IE11 as well.

[lucaelin]

I transpiled my reproduction code and can confirm that the bug also exists in ie11.

[ruphin]

I have found the problem, and I am able to reproduce the issue with Vanilla Web Components. There is a bug in the polyfill when using appendChild() in elements with slotted content that causes the element upgrade path to be skipped. I'm working on a minimal reproduction and a patch which I will submit to the webcomponentsjs repo.

@justinfagnani I think this issue can be closed, I will add a reference in the webcomponentsjs issue once that is filed.

[ruphin]

For reference, I have a reproduction here:

https://codepen.io/ruphin/pen/BPNPgy?editors=1010

[ruphin]

PR for the fix: webcomponents/shadydom#269

[ruphin]

This issue has been resolved with webcomponents/shadydom#271

[lucaelin]

The fix now shipped with the latest webcomponents bundle on npm :+1:
Thank you so much for fixing this ruphin :1st_place_medal: (even if it wasn't your PR that was shipped in the end)!