[w3c/webcomponents] Should innerHTML propagate custom element constructor exceptions? (#525)

As currently specced, innerHTML uses the HTML parser. If element creation throws an exception in the HTML parser, we report the exception (window.onerror etc.) instead of propagating the exception, because normally when using the parser there is nowhere to propagate it to.

This is certainly easiest to spec, but seems like it might be against the original intent. That is, I would kind of expect this to catch the exception:

```js
customElements.define("x-foo", class extends HTMLElement {
  constructor() {
    throw new Error("boo");
  }
});

try {
  document.body.innerHTML = "<x-foo></x-foo>";
} catch (e) {
  // do we get here?
}
```

If we did want this to propagate the exception, I'm not sure the best way to spec it... we can't just say "in the fragment case, propagate the exception" since the fragment case is also used in other places that aren't DOM APIs. We could cheat and say something like "if the JS execution context stack is not empty, propagate the exception" but I might imagine stack inspection is not desirable for implementers? Otherwise I guess we could explicitly set a flag...

/cc @rniwa @dominiccooney @kojiishi @annevk

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/525