Probably need to move its nodeinfo out of the slots and use a bit of mParentPtrBits to signal in-document.

We'll also need to *not* use the nodeinfo from the prototype document, like we do, or at least used to do. Sicking migh have changed that, I seem to recall some discussion about that in a bug somewhere...

Hmm.. i don't really remember this discussion. What did we use it for (and possibly still do use it for) that we don't want to do any more?

nsXULElement doesn't always have its own nodeinfo, it's sometimes using the nodeinfo from its prototype element, which means that we can't get to the elements document through its nodeinfo in all cases. Not sure that's something we need to fix in this particular bug tho...

ah, yeah, i would say that is one of the bigger blockers for fixing this one. In particular we need to make sure we don't slow things down since we'll need to get a nodeinfo from the documents nodeinfo hash every time we create a nsXULElement wrapping a prototype. Though with everything pretty decomtaminated these days it should just come down to a single hash-lookup, which should be fast. We could even have a nsNodeInfoManager::GetNodeInfo that takes another nodeinfo, that way we won't have to construct a new nodeinfoinner-key.

Fixed by the checkin for bug 198533.