[webkit-dev] SharedWorker design doc
Drew Wilson
atwilson at google.com
Wed Apr 22 10:15:55 PDT 2009
That's an excellent point about HTTP auth.
I'm not sure that the "let's just go find an open frame associated with this
worker" solution will work - the reason is that with the ability to
create/pass around message ports, you can end up with the worker associated
with a frame from a different domain (window A creates worker B, then passes
worker B's MessagePort to window C which is running under a different domain
- once window A closes, worker B can't load through window C because it's a
different domain).
Clearly being able to pass MessagePorts around is a bad idea :)
-atw
2009/4/21 Alexey Proskuryakov <ap at webkit.org>
>
> 22.04.2009, в 2:31, Drew Wilson написал(а):
>
> David's take is that long term we'll need to change the loader code so it
>> is not dependent on a specific frame - his upcoming refactoring may
>> facilitate this, but there will still be a significant amount of work to
>> achieve this in WebKit. Over the short term, he suggested that we might be
>> able to suspend the parent frame, such that it still exists for the purposes
>> of allowing associated workers to perform network loads, but it itself no
>> longer has an open window and its active DOM objects are shutdown. When the
>> last child worker exits, the parent frame can be completely discarded.
>>
>
> A problem with this approach is communicating to the user - e.g. asking for
> HTTP authentication credentials. Without an open window, it won't be
> possible to display a sheet, and if we were to display a dialog window
> instead, the user wouldn't know which site needs the credentials.
>
> We do need to make loading work for frameless documents (e.g. to support
> XSLT document() function), but in other cases I'm aware of, we can rely on a
> parent window being visible.
>
> - WBR, Alexey Proskuryakov
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090422/88a62f74/attachment.html>
More information about the webkit-dev
mailing list