803542 - Paris bindings for Document

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

This will require an update to nsINode::GetParentObject(), which currently returns OwnerDoc().

Comment 1

[Boris Zbarsky [:bzbarsky]]

The other thing this will need is figuring out how to handle a [OverrideBuiltins] named getter.

I think we have two implementation strategies.

One is to use our proxy stuff, and modify it to support [OverrideBuiltins].  This has the obvious problem of more complexity in the proxies, possibly more complexity in the proxy ICs in the JIT, and different nodes having different behavior in many cases, possibly causing the JIT mor problems.

The other is to rely on non-proxy jsapi (e.g. class resolve/getter hooks).  The question is whether the spec's requirements are possible to implement with this approach.  

In particular:

1)  [[DefineOwnProperty]] of a property name that we could get via our getter should
    fail.  How do we detect these?
2)  [[Delete]] of such a property name should fail.
3)  [[GetOwnProperty]] of such a property name should call our getter.

In particular, to support #3 we need to be able to do some sort of shadowing setup... :(

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, and a third option is to use a proxy, but a different proxy family.  This would avoid problems with the proxy IC, but all the other problems with the proxy approach would remain.  :(

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK, waldo says we really do need a proxy here.

Given that, I have some questions:

1) efaust, will your stuff still work with a callsite that sees both Document nodes and other nodes?  That is, if we teach the TI code that detects DOM objects that proxies with a certain handler are still DOM objects, will that work out?  Note that this proxy would still have Node.prototype on its proto chain.  And the mechanics of getting the underlying object are similar, but it's in slot 1, not slot 0 (the PROXY_PRIVATE slot, because 0 is taken up by the handler).  Is changing the order of those up for consideration, by the way?  It'd sure help to have identical object layouts for proxies and non-proxies here!

2) We'll need some sort of IC for proxies like Document and HTMLFormElement, especially Document, so we can get to properties that are actually on Document.prototype quickly.  So far those are the _only_ cases that would need this new IC.  The good news is that these always know their underlying property set.  So if we really wanted to, we could even have some sort of concept of "shape" for them, stored on either the JSObject (less good, needs poking of the JSObject from DOM code) or better yet on the native object at some fixed offset, with the offset stored in the JSObject.  Then it seems like the JIT could guard on this in sane ways, and generate useful ICs for getting proto props quickly.

I really wish this stuff were saner, and I totally blame Brendan & co.'s unprincipled use of JS class getter hooks to implement this gunk back when.  :(

Comment 4

[Boris Zbarsky [:bzbarsky]]

Oh, question #1 in comment 3 above is also pretty important because once we do forms iteration over a DOM tree with a <form> in it will run into similar issues.

Comment 5

[Boris Zbarsky [:bzbarsky]]

One note: All the proxy stuff applies to HTMLDocument (in our impl, not necessarily per spec).  So other documents we might be able to convert without too much pain.

Comment 6

[Boris Zbarsky [:bzbarsky]]

We'll also need to uncomment the touch stuff in Document.webidl and make the interface as a whole "pref-controlled" to make that hackery work.