[webkit-dev] Question about Constructors in WebKit JS Bindings

Maciej Stachowiak mjs at apple.com
Mon Jun 22 19:04:30 PDT 2009


On Jun 22, 2009, at 5:54 PM, Drew Wilson wrote:

> I notice that this is a fairly common idiom in the WebKit JS bindings:
>
> 1) Storing away a pointer to the JSDOMGlobalObject in the constructor
>
> JSOptionConstructor::JSOptionConstructor(ExecState* exec,  
> JSDOMGlobalObject* globalObject)
>     : DOMObject(JSOptionConstructor::createStructure(exec- 
> >lexicalGlobalObject()->objectPrototype()))
>     , m_globalObject(globalObject)
> {
>
> 2) Manually marking that JSDOMGlobalObject as in-use:
>
> void JSOptionConstructor::mark()
> {
>     DOMObject::mark();
>     if (!m_globalObject->marked())
>         m_globalObject->mark();
> }
>
> 3) Using that stored-away JSDOMGlobalObject to get a reference to  
> the parent ScriptExecutionContext/Document:
>
> Document* JSOptionConstructor::document() const
> {
>     return static_cast<Document*>(m_globalObject- 
> >scriptExecutionContext());
> }
> static JSObject* constructHTMLOptionElement(ExecState* exec,  
> JSObject* constructor, const ArgList& args)
> {
>     Document* document =  
> static_cast<JSOptionConstructor*>(constructor)->document();
>
>
>
> I'm trying to understand why this is necessary - an alternative  
> would be to just do the following, as JSWorkerConstructor does:
>
> static JSObject* constructHTMLOptionElement(ExecState* exec,  
> JSObject* constructor, const ArgList& args)
> {
>     DOMWindow* window = asJSDOMWindow(exec->lexicalGlobalObject())- 
> >impl();
>     Document* document = window->document();
>
> This avoids having to keep around a reference, have a custom mark()  
> function, etc. This also tightly ties a given constructor to a  
> specific Document object - in this particular example, my javascript  
> code could pass a reference to window.Option into a child iframe,  
> but executing the constructor within that iframe would still  
> reference the original Document object.
>
> What's the motivation for storing away the original Document object  
> in these constructors? I'm writing a constructor for SharedWorker  
> now and I'm trying to figure out which is the correct behavior...

Your proposed alternative will have different behavior. It will use  
the lexical global object of the calling JavaScript function, instead  
of the global object originally associated with the Options  
constructor. In the cross-frame case, this may give different results.  
There is yet a third possibility, which is to save the original  
document, rather than the original Window. This is what the  
XMLHttpRequest spec requires for instance.

I would say the correct behavior here is whatever best matches the  
spec and other browsers. I do not know that offhand, but I suspect  
it's either the current behavior, or saving an original document  
reference rather than an original window reference. I do not think  
other browsers use the lexical global object of the calling function  
in any cases like this.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090622/b36922f5/attachment.html>


More information about the webkit-dev mailing list