Closed Bug 803542 Opened 8 years ago Closed 7 years ago
Paris bindings for Document
This will require an update to nsINode::GetParentObject(), which currently returns OwnerDoc().
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... :(
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. :(
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. :(
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.
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.
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.
Assignee: nobody → peterv
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.