[Webkit-unassigned] [Bug 96522] Give isolated shells a lifecycle like that of main shells
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Sep 12 12:13:25 PDT 2012
https://bugs.webkit.org/show_bug.cgi?id=96522
--- Comment #7 from Dan Carney <dcarney at google.com> 2012-09-12 12:13:51 PST ---
(In reply to comment #6)
> (From update of attachment 163637 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=163637&action=review
>
> >>> Source/WebCore/bindings/v8/ScriptController.cpp:403
> >>> + ownedShell->destroyIsolatedShell();
> >>
> >> Again, we should avoid calling leakPtr. The point of OwnPtr is for the C++ type system to help us call new and delete exactly the right number of times. Calling leakPtr is fighting the type system rather than working with it.
> >>
> >> How about:
> >>
> >> OwnPtr<V8DOMWindowShell> windowShell = it->second.release();
> >> m_isolatedWorlds.remove(it);
> >> windowShell->destroyIsolatedShell();
> >
> > Actually, here, we need to specifically take ownership and leak the pointer as this shell must remain weak. A strong deletion here is a bad thing because of callbacks.
>
> Why you say callbacks, what do you mean? If we're trying to make the lifetime of the isolated window shells the same as the main window shells, that means they need to live as long as the frame lives and not have their lifetime determined by the garbage collector.
Just for the single use shells. The ones that enter evaluateInIsolatedWorld with an uninitializedWorldId or in the test environment with a worldId of 0. I'm not exactly sure how to get one of them to execute outside of the test environment, but I know that PageGroup keeps a bunch of references to them. I 'm happy to remove all that code and leave the references alive until ScriptController deletion. It's just that those particular shell can't be accessed except from callbacks at that point, so we're keeping a lot of stuff alive unnecessarily.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list