1057057 - JS::ubi::Node should understand DOM structure

Status: NEW

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

Description

[Jim Blandy :jimb]

JS::ubi::Node should be able to point to nsINode instances, and understand the parent, children, and sibling links. ubi::Nodes referring to JS shadows for nodes should have an outgoing edge to their nsINode.

JS::ubi::Node is designed to be easily specialized to handle embedding types; the mechanisms are described here:

https://hg.mozilla.org/mozilla-central/file/79ce51162e77/js/public/UbiNode.h#l70

To give each shadow an edge to its nsINode, we would need the JSClass hook described in bug 1056992.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Not that I fully understand ubi::Node, why does it need to specialize nsINode?
Could it not operate on cyclecollectable objects? In case of nsISupports that would be rather simple,
just QI to the right thing and then using Traverse you'd get all the outgoing edges.
non-nsISupports objects might need some macro magic so that they give the cyclecollection participant.

Comment 2

[Jim Blandy :jimb]

If there's some reliable way to retrieve the cycle collector's edges, then we would definitely like to do that. However:

- We want meaningful labels for edges; I don't know what the CC has in that department.
- We need other inspection operations, like in-memory size.
- Iterating over edges must be possible without causing GC or letting arbitrary JS run. QI can run JS.

Comment 3

[Andrew McCreight (out of office until 8/21) [:mccr8]]

The CC edge names are derived from C++ field name, so they are probably not too useful to the user.  It also isn't going to report things the CC doesn't care about, like strings.

The QI operations the CC requires for the callback don't run any JS, or the CC is going to have bad things happen.

Comment 4

[Jim Blandy :jimb]

I think JS::ubi::Node needs more data than the cycle collector, so we probably can't derive ubi::Node specializations from the CC information alone.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

I think we should just extend traverse to cover the use cases ubi needs. Otherwise we pretty much
end up having two copies of traverse.

For naming, CC has a way to give nicer names, and we can add something new there too.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

So if a generic CC based approach is needed, and the tools start from a JS view of the world, 
getting from JS to C++ could happen similar to 
http://mxr.mozilla.org/mozilla-central/source/xpcom/base/CycleCollectedJSRuntime.cpp?rev=f18e606357cd#618
and you could implement your own version of 
http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsCycleCollectionTraversalCallback.h?rev=6fdb8eb0faac#14

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

So get a CC participant from an nsISupports object
http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nsCycleCollector.cpp?rev=91e6e73aa5e6#1419

Comment 8

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: JS::ubi::Node should understand cycle collected objects; WIP