Bug 66037 - Pass additional details to client in didCreateIsolatedContext
Summary: Pass additional details to client in didCreateIsolatedContext
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Aaron Boodman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-10 23:59 PDT by Aaron Boodman
Modified: 2011-08-15 12:52 PDT (History)
2 users (show)

See Also:


Attachments
Patch (11.83 KB, patch)
2011-08-11 00:01 PDT, Aaron Boodman
no flags Details | Formatted Diff | Diff
Patch (11.94 KB, patch)
2011-08-11 00:13 PDT, Aaron Boodman
no flags Details | Formatted Diff | Diff
Patch (11.93 KB, patch)
2011-08-11 12:22 PDT, Aaron Boodman
fishd: review+
fishd: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Boodman 2011-08-10 23:59:49 PDT
Pass additional details to client in didCreateIsolatedContext
Comment 1 Aaron Boodman 2011-08-11 00:01:48 PDT
Created attachment 103586 [details]
Patch
Comment 2 Aaron Boodman 2011-08-11 00:03:41 PDT
We currently have to figure out these details through ugly, and probably unsafe, roundabout ways. Better to just pass them directly.
Comment 3 Adam Barth 2011-08-11 00:05:53 PDT
Comment on attachment 103586 [details]
Patch

LGTM, but we need to great and powerful fishd.
Comment 4 Gyuyoung Kim 2011-08-11 00:07:15 PDT
Comment on attachment 103586 [details]
Patch

Attachment 103586 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/9358092
Comment 5 Early Warning System Bot 2011-08-11 00:10:31 PDT
Comment on attachment 103586 [details]
Patch

Attachment 103586 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/9358094
Comment 6 Aaron Boodman 2011-08-11 00:13:45 PDT
Created attachment 103588 [details]
Patch
Comment 7 Aaron Boodman 2011-08-11 00:14:56 PDT
(In reply to comment #3)
> LGTM, but we need to great and powerful fishd.

I know. I just thought your review would be good for the webcore bit, even though it is small.
Comment 8 Darin Fisher (:fishd, Google) 2011-08-11 11:55:51 PDT
Comment on attachment 103588 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=103588&action=review

> Source/WebKit/chromium/public/WebFrameClient.h:44
> +#include "v8/include/v8.h"

we often just forward declare V8 types.  see WebFrame.h for example.

> Source/WebKit/chromium/public/WebFrameClient.h:312
> +    virtual void didCreateIsolatedScriptContext(WebFrame*, int isolatedWorldId, v8::Handle<v8::Context>) { }

in WebFrame.h, we refer to isolatedWorldId as "worldID"

I assume both of these integers refer to the same thing, so probably would be good to use the same exact variable name for these.

> Source/WebKit/chromium/src/FrameLoaderClientImpl.cpp:85
> +#if WEBKIT_USING_V8

though it really doesn't matter that much, you might go with USE(V8) to match what you do below.  since this file is implementing a WebCore interface, and the WebCore interface uses USE(V8), perhaps this file should do the same?


There are just nits, so R=me.
Comment 9 Aaron Boodman 2011-08-11 12:21:58 PDT
(In reply to comment #8)
> (From update of attachment 103588 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=103588&action=review
> 
> > Source/WebKit/chromium/public/WebFrameClient.h:44
> > +#include "v8/include/v8.h"
> 
> we often just forward declare V8 types.  see WebFrame.h for example.

I tried that initially, but it does not compile. I think this is because the usage in WebFrameClient is in an implemented method, not just a declared one?

> > Source/WebKit/chromium/public/WebFrameClient.h:312
> > +    virtual void didCreateIsolatedScriptContext(WebFrame*, int isolatedWorldId, v8::Handle<v8::Context>) { }
> 
> in WebFrame.h, we refer to isolatedWorldId as "worldID"
> 
> I assume both of these integers refer to the same thing, so probably would be good to use the same exact variable name for these.

Yes, done.

> > Source/WebKit/chromium/src/FrameLoaderClientImpl.cpp:85
> > +#if WEBKIT_USING_V8
> 
> though it really doesn't matter that much, you might go with USE(V8) to match what you do below.  since this file is implementing a WebCore interface, and the WebCore interface uses USE(V8), perhaps this file should do the same?

Done.
Comment 10 Aaron Boodman 2011-08-11 12:22:52 PDT
Created attachment 103656 [details]
Patch
Comment 11 Darin Fisher (:fishd, Google) 2011-08-11 12:52:58 PDT
(In reply to comment #9)
> (In reply to comment #8)
> > (From update of attachment 103588 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=103588&action=review
> > 
> > > Source/WebKit/chromium/public/WebFrameClient.h:44
> > > +#include "v8/include/v8.h"
> > 
> > we often just forward declare V8 types.  see WebFrame.h for example.
> 
> I tried that initially, but it does not compile. I think this is because the usage in WebFrameClient is in an implemented method, not just a declared one?

Ah... this will be the first instance of including v8.h from a public header.  I think you might want to make this be #include <v8.h> since V8 is a third-party library.  That's how we include Skia headers from the WebKit API headers, for example.  The WebKit headers do not assume a common Chromium-style global include root that contains v8.

Also, it looks like v8.gyp puts v8/include on the include search path.  WebCore also just does #include <v8.h>.
Comment 12 Darin Fisher (:fishd, Google) 2011-08-11 12:53:27 PDT
Comment on attachment 103656 [details]
Patch

R=me except for the v8 include issue.
Comment 13 Aaron Boodman 2011-08-15 12:52:36 PDT
Committed r93055: <http://trac.webkit.org/changeset/93055>