Update to use new "report an exception" algorithm in HTML

[jeremyroman]

It's necessary to specify which global these are reported to. This seems to be the event listener callback's realm's global in the event listener case, and the custom element constructor's realm, based on a combination of consistency with the related sites in HTML and browser behavior -- though browser behavior for custom elements isn't consistent in the (unusual) case of custom elements across realms.

Part of whatwg/html#10516.

• At least two implementers are interested (and none opposed): Chrome, WebKit
• Tests are written and can be reviewed and commented upon at:
  • https://chromium-review.googlesource.com/c/chromium/src/+/5789341 (custom element upgrade)
  • https://chromium-review.googlesource.com/c/chromium/src/+/5784046 (event dispatch)
• Implementation bugs are filed:
  • Chromium: https://crbug.com/359909516
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1378265
  • WebKit: n/a (WPTs seem to pass, except for customized built-in elements, which WebKit does not support)
  • Deno (only for aborting and events): n/a (I think)
  • Node.js (only for aborting and events): n/a (I think)
• MDN issue is filed: n/a (this is a very nerdy detail, even for MDN)
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[jeremyroman]

@domenic kind of on the margin of editorial but consistent with the changes made to HTML in whatwg/html#10404; wdyt?

[domenic]

I agree we shouldn't have too high a bar for this change, as it moves us toward consistency and the previous version was just not well-specified at all.

Web platform tests and browser bugs would be nice if you have the time, but I don't want to require them.

I'll not merge immediately since it seems @annevk is back from vacation and he's the editor.

[annevk]

I'm going to push a minor fixup and I don't think we should merge this with the "Editorial:" prefix, but otherwise I'm okay with going ahead with this.

[annevk]

Also, it's really great to see this cleaned up! Thanks Jeremy.

[jeremyroman]

One thing to flag: just found the old discussion at WICG/webcomponents#635 which is somewhat at odds with this, but is more consistent with how callbacks of other sorts, like the event listeners in this same PR, work.

[domenic]

One thing to flag: just found the old discussion at WICG/webcomponents#635 which is somewhat at odds with this, but is more consistent with how callbacks of other sorts, like the event listeners in this same PR, work.

To be clear, you mean that your current PR is more consistent in that it applies the same rules to all callbacks? Or, do you mean the ideas suggested in that old discussion are more consistent?

I think it's the former, in which case, I think our current conclusions are good and I'm happy to stick with them. But if I've misunderstood then let me know.

[jeremyroman]

Yes, the former. I agree, I'm happy with the current conclusions. (Having gone home to my Mac, I can now also say that this seems to match Safari's behavior -- though Safari's muting logic is so aggressive that I get error events with the error censored.)

[annevk]

Thanks again!