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 <a...@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 > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev