Closed Bug 565828 Opened 14 years ago Closed 10 years ago

Investigate making DOM objects non-native, using proxies

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: gal, Unassigned)

References

()

Details

DOM objects are current native, which means we mirror properties into JS land, which uses memory and creates an overhead. If we make them non-native, we eliminate both issues. Expando properties will need extra care. We should also be able to trace better, since we no longer specialize. Instead, C++ code will do all the dispatching on vtbls instead of blowing up our tree. Its not clear to me what impact quickstubs have on this, so this needs more discussion and investigation.
Depends on: harmony:proxies
Summary: Investigate make DOM objects and NPAPI non-native, using proxies → Investigate making DOM objects non-native, using proxies
If they were non-native, would that also make it simpler to get to the underlying C++ object from the JSObject?
And note that we've been moving towards non-vtbl things in custom quickstubs, in fact...
Yeah, pulling out the C++ object should be trivial. It can sit in a slot of the DOM JS object (which is a proxy). Though, there might be an advantage to keeping them native and using the JS-side dispatch (if we make DOM objects non-native, you have to rely on C++ dispatch, the DOM object itself will be totally naked). I filed this bug with a big question mark. I would like to discuss this and figure out what the trade-offs are.
Note that we can still use a PIC, even if the DOM object is non-native.

Also, I think this bug is related to bug 565825 which just got invalidated. DOM uses slotless shared properties, which of course we wouldn't need if DOM objects are non-native. If that bug doesn't get re-opened, this one probably is going to get invalidated next.
Here is how the C++ object would be pulled out. The DOM object (proxy) has 2 slots: handler and private. We probably would want one singleton handler by DOM node type, and the private slot holds the C++ DOM object. With those two you can PIC a straight line to the C++ method you want to call (getter, setter, whatever).
Host objects in the IE DOM are evil, webdevs hate them. Don't inflict them on Gecko.

/be
The bug URL points to WebIDL ES binding language, which seems to say interface attributes and methods show up on prototypes.

Harmony Proxies are attractive for healing the rift between "host objects" and the built-in ("native") objects. They're also attractive, ignoring the WebIDL spec issue which matters for interop, to avoid the shadow-able proto-properties in favor of what look like "own" props. WebKit does something like this, but last we spoke, Oliver Hunt said they are changing.

So the WebIDL spec trumps this bug. Maybe we should argue with the WebIDL spec, though. To do so, please use the public-script-coord@w3.org list (cc'ing es-discuss@mozilla.org seems to be the thing to do lately -- duplicative for many, but can be dialed down if enough people complain).

/be
Depends on: 566818
No longer depends on: 566818
As far as I can tell, there is one thing that ES5 without proxies cannot emulate and on which the WebIDL spec doesn't trump this bug: live objects. NodeList, HTMLCollections, NamedNodeMaps (are there others?) are live objects. Once they have been created, they are expected to be in sync with the DOM tree whenever they are accessed. Without proxies, there is no way I can think of for these objects to be synchronized with the DOM tree they've been created from.

I'll take the example of NodeList returned by document.getElementsByTagName. I see 2 main implementations strategies with proxies:
- The function creates listeners to DOM Mutation events (or whatever replaces them since they are deprecated by DOMEvent Lvl 3) and returns a proxy. Each time something happens which can affect the NodeList, the proxy is alerted, changes its internal state and is always ready to answer in constant time.
- The function creates a proxy for which the get/getOwnProperty handler method, when used on a numeric value, traverses the tree and retrieve the actual value. No events, but longer call. Gives the impression of being live anyway. (this one may cause a O(n²) (n is number of elements in the DOM tree) algorithm if the NodeList is traversed in a for-loop)

I'm not a DOM specialist, but for the rest, I think that everything can be done with ES5 without proxies.
We were the ones who argued for properties living on the proto, for various reasons.

David, we have a non-proxy implementation of the DOM right now, but it involves various internal hooks that are not exposed to JS code.
So https://github.com/andreasgal/dom.js is where the code is for this bug?
dom.js is just a thought experiment, we don't really have plans for that in ff yet, but its a nice way to experiment with proxies for dom bindings
I'm going to declare this fixed enough.  The things that need proxies are using them; the rest are using sane objects without bizarre behavior.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.