Re: Forking host object prototype

Rumith wrote:
> Modifying the HTMLDivElement itself wouldn't work, because I need to
> use several different such "subclasses", and I'll need regular div
> elements as well.

If that's the case, then you need to explicitly add expandos on the 
particular nodes you want to have extra properties on.  In particular, 
you can't change the prototype of actual HTML <div> elements.

> var Block = function() {};
>   Block.prototype = HTMLDivElement.prototype;
>   Block.prototype.decorate = function() {
>       this.style.backgroundColor = "#aaaaff";
>   };
 >
 > var blockInstance = new Block;

That will create a JSObject with the same prototype as HTML <div> 
elements, but without the right private pointer, with the wrong JSClass, 
etc.  As soon as you pass it to any DOM method you'll get an exception, 
because there is no actual DOM node backing this JSObject.

> Error: [Exception... "Node cannot be inserted at the specified point
> in the hierarchy"  code: "3" nsresult: "0x80530003
> (NS_ERROR_DOM_HIERARCHY_REQUEST_ERR)"  location: "...."]

Right.  See 
http://hg.mozilla.org/mozilla-central/annotate/dc71e84d6cb6/content/base/src/nsGenericElement.cpp#l3737

In this case, the fake nsIDOMNode XPConnect synthesizes when you make 
the appendChild call is not an nsIContent.

> The blockInstance variable is of type [xpconnect wrapped native
> prototype], according to an alert(blockInstance) call.

Yep.

> How do I convert blockInstance to a regular DOM element so that it can
> be inserted into the hierarchy?

You don't.  If you want an actual DOM element you need to create it by 
calling createElement.  Using the JS builtin |new| thing doesn't do it.

Followup set to .dom, which is where this sort of thing probably belongs.

-Boris