Re: [w3c/webcomponents] The custom element state when constructor thrown (#533)

Interesting. So the concrete test case is

```html
<script>
let shouldThrow = true;
customElements.define("x-bad", class XBad extends HTMLElement {
  constructor() {
    super();
    if (shouldThrow) {
      throw new Error("bad");
      shouldThrow = false;
    }
  }
});
</script>

<x-bad></x-bad>
```

Per the current spec this will try to create an XBad, then fail, but then upon insertion, try to "upgrade" from HTMLUnknownElement to XBad, and succeed. This is especially weird since the "upgrade" goes laterally across the hierarchy (i.e. from HTMLUnknownElement to XBad, instead of from HTMLElement to XBad).

One "solution" would be to say that this is an OK edge case that emerges from the semantics, but we should probably clean up the potential for a lateral transition, so make it HTMLElement instead of HTMLUnknownElement.

Otherwise, if we want to say that throwing in your constructor means we should never try to upgrade you, then the most straightforward solution I can think of is to add a new custom element state, "unupgradeable", which we set if the constructor fails. Then any future upgrades or try-to-upgrades would bail out if they see this state. We would probably also use this in other cases, such that if upgrading fails once, we should never try it again.

What do people think would be better?

---
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/533#issuecomment-232103410