Re: [webkit-dev] SharedWorker design doc
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
Re: [webkit-dev] SharedWorker design doc
Following up on this - is using a dialog for HTTP auth for worker requests really such a bad thing? What if we only do this as a fallback, in the case that the initiating window is closed? It seems more like a UX issue that the application itself could manage (if you want to use HTTP Auth from your workers, then be sure to force the auth to happen before your window closes). -atw 2009/4/22 Drew Wilson atwil...@google.com 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
Re: [webkit-dev] SharedWorker design doc
On Apr 22, 2009, at 11:54 AM, Drew Wilson wrote: Following up on this - is using a dialog for HTTP auth for worker requests really such a bad thing? What if we only do this as a fallback, in the case that the initiating window is closed? It seems more like a UX issue that the application itself could manage (if you want to use HTTP Auth from your workers, then be sure to force the auth to happen before your window closes). It's not only a problem for the Web application but also a problem for the browser: 1) We don't want the UI to be confusing even if a Web application is written without sufficient caution. 2) We don't want to create a phishing risk via SharedWorkers throwing up auth dialogs that appear to belong to another window. One possible solution is that if the frame that created the SharedWorker originally is now gone, then any network request that would lead to an authentication prompt or other kind of prompt fails. That allows the solution you propose for Web apps, but prevents confusion and abuse in the case of malicious or poorly written Web apps. Regards, Maciej -atw 2009/4/22 Drew Wilson atwil...@google.com 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorker design doc
That's also a reasonable option - so we'd just return a 401 error to the caller if the initiating window is unable to gather credentials. -atw 2009/4/22 Maciej Stachowiak m...@apple.com On Apr 22, 2009, at 11:54 AM, Drew Wilson wrote: Following up on this - is using a dialog for HTTP auth for worker requests really such a bad thing? What if we only do this as a fallback, in the case that the initiating window is closed? It seems more like a UX issue that the application itself could manage (if you want to use HTTP Auth from your workers, then be sure to force the auth to happen before your window closes). It's not only a problem for the Web application but also a problem for the browser: 1) We don't want the UI to be confusing even if a Web application is written without sufficient caution. 2) We don't want to create a phishing risk via SharedWorkers throwing up auth dialogs that appear to belong to another window. One possible solution is that if the frame that created the SharedWorker originally is now gone, then any network request that would lead to an authentication prompt or other kind of prompt fails. That allows the solution you propose for Web apps, but prevents confusion and abuse in the case of malicious or poorly written Web apps. Regards, Maciej -atw 2009/4/22 Drew Wilson atwil...@google.com 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorker design doc
I followed up with David Levin, who has been working on some chrome-internal refactoring of the loader code necessitated by the fact that workers in Chrome run in a different process from the loading frame. 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. I'll need to dig further into this, but I wanted to see whether you thought this was a reasonable approach and what obstacles there might be to implementing this. -atw 2009/4/18 Alexey Proskuryakov a...@webkit.org Hi Drew, Thanks for the detailed proposal, it's great to have one. Prior to diving into threading details, I'd like to clarify a background assumption that doesn't seem to be mentioned in the proposal. How does a SharedWorker relate to the browsing context that created it? Specifically, we probably don't want a SharedWorker to be a top browsing context, because that would be an easy way to subvert same origin cookie policy. And since loading in WebCore can only happen when there is a Frame, what will happen to a SharedWorker whose original frame goes away? 18.04.2009, в 8:55, Drew Wilson написал(а): Any feedback would be appreciated, especially for some of the cross-threading and worker lifecycle issues. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorker design doc
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
Re: [webkit-dev] SharedWorker design doc
Hi Drew, Thanks for the detailed proposal, it's great to have one. Prior to diving into threading details, I'd like to clarify a background assumption that doesn't seem to be mentioned in the proposal. How does a SharedWorker relate to the browsing context that created it? Specifically, we probably don't want a SharedWorker to be a top browsing context, because that would be an easy way to subvert same origin cookie policy. And since loading in WebCore can only happen when there is a Frame, what will happen to a SharedWorker whose original frame goes away? 18.04.2009, в 8:55, Drew Wilson написал(а): Any feedback would be appreciated, especially for some of the cross- threading and worker lifecycle issues. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorker design doc
Those are good questions - I've been primarily concentrating on the mechanisms around worker lifecycle management so I'm not entirely up to speed on the loadng mechanisms. The resource loading issues for dedicated Workers are the same as for SharedWorkers, since dedicated Workers can outlive their parent window closes once we support passing MessagePorts through Worker.postMessage(). I know that David Levin has been doing work on enabling loading within workers - I've CC'd him in hopes he might have some insights here. -atw 2009/4/18 Alexey Proskuryakov a...@webkit.org Hi Drew, Thanks for the detailed proposal, it's great to have one. Prior to diving into threading details, I'd like to clarify a background assumption that doesn't seem to be mentioned in the proposal. How does a SharedWorker relate to the browsing context that created it? Specifically, we probably don't want a SharedWorker to be a top browsing context, because that would be an easy way to subvert same origin cookie policy. And since loading in WebCore can only happen when there is a Frame, what will happen to a SharedWorker whose original frame goes away? 18.04.2009, в 8:55, Drew Wilson написал(а): Any feedback would be appreciated, especially for some of the cross-threading and worker lifecycle issues. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
