See bug 747285. This is step (A).
The easiest way to do this seems to be to teach TI about the DOM subtyping relations. It shouldn't be too hard to extend the TypeObjects in an opt-in way to include an array similar to |mInterfaceChain| in DOMJSClass, and then just copy that information in from the prototype as we create them in JS_NewObject() adding the DOM type of the instance to the new TypeObject as well. The hard part is the properties themselves. We need TI to know what prototypes the DOM property getters are supposed to be attached to, so that we cannot create a property with the appropriate name and signature on the wrong DOM class and have the C++ gladly do something totally wrong. This we can probably store in the Property object hanging off the TypeObject, which we can look into in typeObj->addProperty().
Having done some more discussion, it seems wiser to proceed on this matter in the following way: TI will need to be informed at creation time, similar to the way that typed arrays are handled, if the type object represents DOM objects. Any time something that isn't a DOM object is created, it will unset the flag. This flag will the tell us that it's safe to investigate DOM related optimizations. The metadata attached to the getters and setters will utilize an unused word in the u.native half of the union to sneak a pointer to a statically created struct of DOM metadata into the JSFunction. This field will be set exactly in the DOM case, and NULL otherwise. This will allow us to get the metadata we need into the engine.