Last Comment Bug 747286 - Create a way to attach DOM-related metadata to JS getters and setters
: Create a way to attach DOM-related metadata to JS getters and setters
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 Mac OS X
-- normal (vote)
: ---
Assigned To: Eric Faust [:efaust]
: Jason Orendorff [:jorendorff]
Depends on: 766448
Blocks: 747285 747287
  Show dependency treegraph
Reported: 2012-04-19 20:23 PDT by Boris Zbarsky [:bz] (still a bit busy)
Modified: 2012-08-08 11:57 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Boris Zbarsky [:bz] (still a bit busy) 2012-04-19 20:23:01 PDT
See bug 747285.  This is step (A).
Comment 1 User image Eric Faust [:efaust] 2012-06-15 17:42:00 PDT
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().
Comment 2 User image Eric Faust [:efaust] 2012-06-19 21:08:18 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.