Bug 27104 - [V8] evaluateInNewContext should send a notification that a context was created
Summary: [V8] evaluateInNewContext should send a notification that a context was created
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Matt Perry
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-08 17:22 PDT by Matt Perry
Modified: 2009-07-14 15:35 PDT (History)
1 user (show)

See Also:


Attachments
simple patch (1.13 KB, patch)
2009-07-08 17:23 PDT, Matt Perry
no flags Details | Formatted Diff | Diff
new notification (3.63 KB, patch)
2009-07-10 17:54 PDT, Matt Perry
fishd: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Perry 2009-07-08 17:22:22 PDT
Content scripts want this notification as well.
Comment 1 Matt Perry 2009-07-08 17:23:56 PDT
Created attachment 32490 [details]
simple patch
Comment 2 Darin Fisher (:fishd, Google) 2009-07-09 13:07:23 PDT
Comment on attachment 32490 [details]
simple patch

> Index: WebCore/bindings/v8/V8Proxy.cpp
> ===================================================================
> --- WebCore/bindings/v8/V8Proxy.cpp	(revision 45651)
> +++ WebCore/bindings/v8/V8Proxy.cpp	(working copy)
> @@ -1050,6 +1050,8 @@ void V8Proxy::evaluateInNewContext(const
>      // original context.
>      global->Set(v8::String::New("contentWindow"), windowGlobal);
>  
> +    m_frame->loader()->client()->didCreateScriptContext();
> +
>      // Run code in the new context.
>      for (size_t i = 0; i < sources.size(); ++i)
>          evaluate(sources[i], 0);

Shouldn't we also call didDestroyScriptContext()?
Comment 3 Matt Perry 2009-07-09 13:19:53 PDT
(In reply to comment #2)
> Shouldn't we also call didDestroyScriptContext()?

There's no definitive place where this context is destroyed.  It's just garbage collected when it's not used.

The chrome side of this change listens for its GC, and also associates sub-contexts with their frame so that we can notify the script and clean up after it.
Comment 4 Darin Fisher (:fishd, Google) 2009-07-09 21:21:17 PDT
> > Shouldn't we also call didDestroyScriptContext()?
> 
> There's no definitive place where this context is destroyed.  It's just garbage
> collected when it's not used.

A didCreateScriptContext without a corresponding didDestroyScriptContext seems like a recipe for memory leaks.  Someone not knowing any better might assume that for each "create" call they will get a "destroy" call, and on the destroy call expect to free resources.  Can you do anything to mitigate that kind of problem?
Comment 5 Matt Perry 2009-07-10 12:50:13 PDT
(In reply to comment #4)
> Can you do anything to mitigate that kind of
> problem?

The first idea I had was to add a GC callback, and send out the didDestroyScriptContext then.  Unfortunately, since the content script context can outlive the frame, and we need to use the frameloader to send the event, we have nowhere to send it.  Maybe these events should be on the ChromiumClient API?
Comment 6 Matt Perry 2009-07-10 17:54:32 PDT
Created attachment 32598 [details]
new notification

OK, instead of having didDestroyScriptContext only sometimes getting called, I renamed the create/destroy notifications for frames, and added a new one for evaluateInNewContext.  Hopefully this will make it clearer to callers what to expect.
Comment 7 Matt Perry 2009-07-14 15:35:19 PDT
Committed http://trac.webkit.org/changeset/45871.