Add HostEnsureCanAddPrivateElement definition.

[mgaudet]

Disallow the addition of private fields to Location and WindowProxy object

Fixes #7952

• At least two implementers are interested (and none opposed):
  • Gecko
  • Chromium
• Tests are written and can be reviewed and commented upon at:
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1785309
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1355126
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1726039
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=244177
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …

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

---

/acknowledgements.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/webappapis.html ( diff )

[mgaudet]

(There is a test which will need to be updated and moved to WPT here https://phabricator.services.mozilla.com/D141877 )

[mgaudet]

A note: I will be heading on parental leave at any time now; if need be please move on with this without me, and I will return to this work come my return.

[domenic]

Thank you! Since you mentioned your leave, I pushed a quick fixup commit myself instead of doing a review with my nits. Normatively everything looks great.

The only blocker here then is making sure we have tests in the web platform tests repo. A particularly tricky case I noticed is if you make classes that inherit from WindowProxy or Location; let's be sure that is tested too.

Other optional additions:

• Would you like to add yourself to the acknowledgments section?
• We could explain the motivation for this in a <p class="note"> after the algorithm, to help future readers.

[domenic]

I'm a little unsure on the most rigorous way to phrase this for WindowProxy. "implements" doesn't work since it generally applies to platform objects; Window is a platform object, but WindowProxy is not. Maybe we should say "has a [[Window]] internal slot"?

I also was thinking maybe we should check Window objects, but upon consideraiton WindowProxy seems right. This algorithm will only ever get called with WindowProxy, right? Nobody is going to be able to get ahold of a Window except spec text, and the spec text in html.spec.whatwg.org/#the-windowproxy-exotic-object will never hand the WindowProxy to someone who might trigger this, I believe.

[mgaudet]

I waffled a bit on that front myself; I came to a similar conclusion. My understanding is that no user code should ever see a Window object, and so specifying this hook in terms of the WindowProxy made sense to me. Editorially I wasn't sure of the best way to write it; thanks for your review.

[mgaudet]

Thank you! Since you mentioned your leave, I pushed a quick fixup commit myself instead of doing a review with my nits. Normatively everything looks great.

Thank you very much!

The only blocker here then is making sure we have tests in the web platform tests repo. A particularly tricky case I noticed is if you make classes that inherit from WindowProxy or Location; let's be sure that is tested too.

I'll try to resuscitate my test case tomorrow, and add that extra dimension as well.

Other optional additions:

* Would you like to add yourself to the acknowledgments section?

* We could explain the motivation for this in a `<p class="note">` after the algorithm, to help future readers.

I'll work on this if I can tomorrow.

Thanks again!

[mgaudet]

A particularly tricky case I noticed is if you make classes that inherit from WindowProxy or Location; let's be sure that is tested too.

I was playing around with this: is it actually possible to construct a class which extends from WindowProxy/Location at all?

• window / window.location aren't constructors directly.
• Their prototypes have a .constructor property, however, it seems that we cannot actually use said constructor; new (class extends window.location.__proto__.constructor {}) / new (class extends window.__proto__.constructor {}) throws an Illegal Constructor error.

[mgaudet]

The WPT test case for this hook is inbound; see https://bugzilla.mozilla.org/show_bug.cgi?id=1785309 and web-platform-tests/wpt#35520