[Webkit-unassigned] [Bug 70836] [chromium] add swapOut method to WebFrame

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 28 11:05:06 PDT 2011


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





--- Comment #6 from Karl Koscher <supersat at chromium.org>  2011-10-28 11:05:06 PST ---
> I think this function belongs in the Chromium repository instead.  We should just
> expose the necessary primitives through the WebKit API here.  For example, I think
> it makes sense to have a WebDocument::create() function and a WebFrame::setDocument
> function.  Perhaps WebFrame::setDocument can call m_frame->loader()->clear() before
> changing the document?
> 
> Basically, the concept of "swapping out" doesn't belong in WebKit.

I agree that it seems strange to put this in WebKit. However, this is just an interm step towards the long-term goal of getting postMessage to work across process boundaries (http://crbug.com/99202). The way we're thinking of implementing this is to point a swapped out WebCore::Frame to a proxy DOMWindow object that knows how to redirect postMessages (and possibly other allowed cross-origin calls) to chromium. It seems like the cleanest way to do this is to put the proxy DOMWindow in WebKit/chromium, which means that we need a way of constructing one from chromium. The plan was to have the swapOut method construct and install this proxy DOMWindow.

As strange as that may seem, it seems even stranger to add the proxy DOMWindow to chromium. The point of the chromium port in WebKit is to expose
a clean API between chromium and WebKit, and putting the proxy DOMWindow in
chromium would smear that clean boundary.

Of course, if you have other ideas on how to proceed, I'd certainly welcome them!

-- 
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