WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
27104
[V8] evaluateInNewContext should send a notification that a context was created
https://bugs.webkit.org/show_bug.cgi?id=27104
Summary
[V8] evaluateInNewContext should send a notification that a context was created
Matt Perry
Reported
2009-07-08 17:22:22 PDT
Content scripts want this notification as well.
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
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Matt Perry
Comment 1
2009-07-08 17:23:56 PDT
Created
attachment 32490
[details]
simple patch
Darin Fisher (:fishd, Google)
Comment 2
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()?
Matt Perry
Comment 3
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.
Darin Fisher (:fishd, Google)
Comment 4
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?
Matt Perry
Comment 5
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?
Matt Perry
Comment 6
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.
Matt Perry
Comment 7
2009-07-14 15:35:19 PDT
Committed
http://trac.webkit.org/changeset/45871
.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug