[Webkit-unassigned] [Bug 110779] WebKit API for enabling DOM logging for certain worlds

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=110779





--- Comment #24 from Adam Barth <abarth at webkit.org>  2013-02-28 00:41:49 PST ---
(In reply to comment #23)
> (In reply to comment #22)
> > (In reply to comment #21)
> > > (In reply to comment #19)
> > > > (From update of attachment 190556 [details] [details] [details] [details])
> > > > View in context: https://bugs.webkit.org/attachment.cgi?id=190556&action=review
> > > > 
> > > > > Source/WebKit/chromium/public/WebCoverWrapping.h:54
> > > > > +    // Sets the provided log object for the world identified 
> > > > > +    // by worldID (worldID may be 0 identifying the main world).
> > > > 
> > > > I thought we weren't going to support installing a logger for the main world?
> > > 
> > > Logging can be enabled for any world. The guarantee is that the DOM bindings for all
> > > those worlds for which logging is not enabled would not be affected. We include the main world
> > > to log DOM activity inside extension background pages.
> > 
> > I see.  Won't you need to do the hash lookup to see if there is a logger configured for a world?  That seems like it will impact performance even if no logger is configured.
> 
> Yes for all worlds there will be a one-time HashMap lookup while initializing the context. (we consider the existence of a logger as an indication from the chromium side that logging should be enabled for that world).

Ah, initialization-time lookup makes more sense.  I remember your saying that you'd then configure the wrappers different when there's logging involved.

> > > The logger will be invoked on all DOM API calls that are covered by the policy. 
> > > To begin with we will have a small policy that includes critical calls like document.write, document.createElement, document.appendChild, window.location and so on.
> > 
> > Do you plan to teach WebKit about this policy, or does WebKit always just call the log function?  Maybe the answer to this question is related to my previous question and the issue is just that I don't understand this part of the design.
> 
> As mentioned earlier, think of the policy as a set of pairs of the form <cName,pName>. Each such pair means that all access to property pName of objects with className= cName must be logged.
> 
> This set will be hard-coded into the source code, in some struct that lives in WebCore.

Oh, I see.  Why hard-coded?  It seems like something that should be configurable by the embedder.

> If logging is enabled for the world then the methods batchConfigureCallbacks and configureAttribute in V8DOMConfiguration would consult this policy struct for every DOM attribute that they configure. If the attribute is found in  the policy struct then the methods will take a different branch and install wrappers for the attribute, otherwise they will behave the way they are right now. The actual patch makes a few other changes as well, but the gist is what is described above.
> 
> Note that in the current design the policy is the same for all worlds and it is hard-coded.
> 
> Later, if needed, we can have the policy struct also come from the Chromium side by proving a route 
> through the WebKit API. Furthermore, the policy struct could also be different for each world. 

I see.

> May be the word policy here is confusing?

I'd call it a logging filter, but maybe I've drunk the Python logging coolaid too long.

Ok, this is making more sense now.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.