This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1371 [details] Test window.close() from sandbox - closeTestOpener.html starts the test. As part of discussions on bug 20939, I've been asked to raise this bug. The purpose is to look at whether window.close() should be affected by sandboxing rules. In the specification at http://www.w3.org/html/wg/drafts/html/master/browsers.html#dom-window-close, it states: "The close() method on Window objects should, if the corresponding browsing context A is script-closable and the browsing context of the script that invokes the method is allowed to navigate the browsing context A, close the browsing context A." The "allowed to navigate" rules at http://www.w3.org/html/wg/drafts/html/master/browsers.html#allowed-to-navigate, don't include the sandboxing rules, but sandboxing could actually affect whether navigation takes place. So the question is, if navigation of a browsing context is blocked by sandboxing rules, should window.close() also be blocked? I believe it should, as (for example) it seems wrong that a sandboxed browsing context is not allowed to navigate top, but is allowed to close it. I did a quick test to see what happens in a sandbox with allow-scripts, but not allow-top-navigation. closeTestOpener.html starts the test. (This test was done in early May, I'm sorry I don't have the versions that were used.) Firefox, IE10, Chrome and Opera all seem to block the direct navigation of top with window.open(..., "_top"). Only Chrome stops the window.top.close(). It gives the same error as for the navigation, which complains that you are trying to navigate top without allow-top-navigation. As I have said, Chrome's behaviour seems correct to me. Thanks, Bob
Ian - thought you would want to be included on this.
Acting as devil's advocate: The difference is that navigation is about going to a new page, whereas close() is about closing the current page. Closing the current page is already only allowed in a very limited set of cases — where script opened the page in the first place, or where it's the only page that's been opened in that browsing context — and sandboxing can only close the page in the case where scripts are enabled despite sandboxing being used. But yeah, it seems like a sandboxed script shouldn't be able to close a tab. Do you want this blocked by the "sandboxed top-level navigation browsing context flag" (so you can reenable it with 'allow-top-navigation', meaning that an embedded sandboxed ad can close your whole page) or by the "sandboxed navigation browsing context flag" (so it's always blocked)? I'm leaning towards the latter.
(In reply to comment #2) > Acting as devil's advocate: > > The difference is that navigation is about going to a new page, whereas > close() is about closing the current page. Closing the current page is > already only allowed in a very limited set of cases — where script opened > the page in the first place, or where it's the only page that's been opened > in that browsing context — and sandboxing can only close the page in the > case where scripts are enabled despite sandboxing being used. > > But yeah, it seems like a sandboxed script shouldn't be able to close a tab. Thanks for the quick response. I do appreciate that closing is different to navigation, although perhaps closing can be thought of as navigating to dev://null :) I also agree that this probably isn't causing major problems, because, as you say, the restrictions on close() are already quite severe. It's more tidying up a loose end. > Do you want this blocked by the "sandboxed top-level navigation browsing > context flag" (so you can reenable it with 'allow-top-navigation', meaning > that an embedded sandboxed ad can close your whole page) or by the > "sandboxed navigation browsing context flag" (so it's always blocked)? I'm > leaning towards the latter. I was thinking of the former, just because it seems to tie in with the existing rules. By which I mean ... navigating top is normally allowed unless sandboxed and this restriction is lifted by allow-top-navigation. So, taking the other restrictions as read, as you can normally close because you are "allowed to navigate" top, it seems reasonable that you can when sandboxed with allow-top-navigation. I know that "allowed to navigate" isn't affected by sandboxing, but it makes sense to me. (I've also left a thought about the use of "allowed to navigate" as a term in bug 20939) Finally, given that you could navigate top to a non-sandboxed document and close anyway, it might be a little bit academic. I've just checked and Chrome allows you to close top with allow-top-navigation, but blocks it otherwise. Cheers, Bob
(In reply to comment #3) > > Finally, given that you could navigate top to a non-sandboxed document and > close anyway, it might be a little bit academic. That's a pretty good point. Done. BTW, the spec I edit is the one at http://whatwg.org/html; the W3C one you cite is a fork that has a number of differences (some would call them "errors") in it.
Checked in as WHATWG revision r7984. Check-in comment: Sandboxing: prevent pages from closing their top-level browsing context (unless they can navigate it, in which case, whatever) http://html5.org/tools/web-apps-tracker?from=7983&to=7984
Created attachment 1378 [details] Test closing a window from a sandboxed iframe that didn't open it. Hi Ian, Really sorry about this ... you must be sick of me by now. I'd originally thought that this should cover all cases where navigation would be blocked by sandboxing. I've added another test case, which is possibly the only other relevant one anyway. In this one the sandboxed iframe is trying to close a top-level browsing context that is not its top. I've added an unsandboxed iframe to show the difference. Chrome seems to block the close from the sandboxed iframe, but IE and Firefox both allow it, while correctly blocking the navigation. Chrome doesn't seem to put out any sort of error, it just does nothing. For chrome you have to run the test from a proper web server, because it doesn't allow access to parent just from the file system - I think it sees them as from a different origin. So I think the conditions for being allowed to close should be something like: * The corresponding browsing context A is script-closable. * The browsing context of the incumbent script is allowed to navigate the browsing context A. * The active sandboxing flag set of the document of the incumbent script would not cause the navigate algorithm to abort the navigation of the browsing context A. The last point could link to the navigate algorithm. I'm sure you'd put it more eloquently though, I was try to avoid the words not allowed, because of the second bullet point. Cheers, Bob
Are you saying in this case that it _should_ be able to close it, or that it _shouldn't_ be able to close it? I'm not sure I understand which you want and why you want it that way.
(In reply to comment #7) > Are you saying in this case that it _should_ be able to close it, or that it > _shouldn't_ be able to close it? I'm not sure I understand which you want > and why you want it that way. I knew that my wording needed some work. I mean that it shouldn't be able to close a browsing context if it is blocked from navigating it because of sandboxing. The reason is the same as for when it is your own top. It seems wrong that a browsing context is blocked from navigating another browsing context, but is allowed to close it. Hopefully, I've explained that more clearly, but I'm not convinced :)
Oh, I see. I screwed up the way I used the sandboxing stuff. I need to basically use the same prose as in the navigation section: http://www.whatwg.org/specs/web-apps/current-work/#sandboxLinks Possibly by factoring that out. "Really allowed to navigate", or something...
(In reply to comment #9) > Oh, I see. I screwed up the way I used the sandboxing stuff. Well, I wouldn't say that. I should have been clearer, in Comment 3, that this was just an example. > I need to basically use the same prose as in the navigation section: > > http://www.whatwg.org/specs/web-apps/current-work/#sandboxLinks > > Possibly by factoring that out. "Really allowed to navigate", or something... That would make sense. Maybe a "Blocked from navigating" section. This could possibly go under "6.1.4 Security" and start something like: A browsing context A is blocked from navigating a second browsing context B if ... This would probably just include the sandboxing stuff at the moment. It could possibly be referenced from section "6.1.6 Browsing context names" as well as "6.6.1 Navigating across documents" and the bit on window.close(). Also, maybe the "allowed to navigate" could be renamed to "allowed to attempt to navigate", to make things really clear. Although that is a bit of a mouthful. You could then possibly remove the note on sandboxing that you added on my request for bug 20939 :) Cheers, Bob
Checked in as WHATWG revision r8045. Check-in comment: Stop one: rename 'allowed to navigate' to 'friends with' http://html5.org/tools/web-apps-tracker?from=8044&to=8045
Checked in as WHATWG revision r8046. Check-in comment: Factor out some steps from the top of the navigation algorithm to define 'allowed to navigate'. http://html5.org/tools/web-apps-tracker?from=8045&to=8046
Checked in as WHATWG revision r8047. Check-in comment: Change how window.close() decides what you can close to make more sense. http://html5.org/tools/web-apps-tracker?from=8046&to=8047
Checked in as WHATWG revision r8048. Check-in comment: Remove a note that is now more confusing than helpful. http://html5.org/tools/web-apps-tracker?from=8047&to=8048
Thanks Ian. I'm not sure about the term "friends with" as this implies a mutual relationship, which this is not. However paraphrasing from a reply on another bug ... unless a better term can be suggested then it should stand. Anyway, once you accept the term, then I think this all hangs together logically and is clearer than before. I did wonder whether there should be a line at the start of the new "allowed to navigate" algorithm stating: 1. If A is not friends with B, then abort these steps negatively. Just in case there is away that a browsing context can initiate a navigation on another browsing context without being friends. This doesn't appear to have been in the previous version, so I imagine it is OK. Cheers, Bob
Reopening to let Hixie ponder about comment 15
(In reply to comment #15) > > I'm not sure about the term "friends with" as this implies a mutual > relationship, which this is not. > However paraphrasing from a reply on another bug ... unless a better term > can be suggested then it should stand. Yeah, I'm not a fan of the term either. The term implying a mutual relationship is an interesting point. I've tried renaming it to "is ". > I did wonder whether there should be a line at the start of the new "allowed > to navigate" algorithm stating: > > 1. If A is not friends with B, then abort these steps negatively. > > Just in case there is away that a browsing context can initiate a navigation > on another browsing context without being friends. Is there any way this can happen? (I don't like giving redundant requirements, because they tend to hide errors in the spec. Unlike software, which should have defense in depth because it's more important that it not break than that it be thought through all the way, in a spec it's more important that we do things intentionally and have it thought through all the way than that it not break. IMHO.)
> relationship is an interesting point. I've tried renaming it to "is ". Er... "is familiar with". Just "is" would be a whole different ball game...
Checked in as WHATWG revision r8136. Check-in comment: Try renaming 'friends with' to 'familiar with'. http://html5.org/tools/web-apps-tracker?from=8135&to=8136
(In reply to comment #18) > > relationship is an interesting point. I've tried renaming it to "is ". > > Er... "is familiar with". Just "is" would be a whole different ball game... Sorry, I've been away on holiday, so I've not kept up with all of my mail. I think "is familiar with" works well. (In reply to comment #17) > (In reply to comment #15) > > I did wonder whether there should be a line at the start of the new "allowed > > to navigate" algorithm stating: > > > > 1. If A is not friends with B, then abort these steps negatively. > > > > Just in case there is away that a browsing context can initiate a navigation > > on another browsing context without being friends. > > Is there any way this can happen? (I don't like giving redundant > requirements, because they tend to hide errors in the spec. Unlike software, > which should have defense in depth because it's more important that it not > break than that it be thought through all the way, in a spec it's more > important that we do things intentionally and have it thought through all > the way than that it not break. IMHO.) Not that I've spotted, it was just a belt and braces thing. I've only really been looking at this part of the spec for sandboxing, so I'll have a think about it. Given we should have been through the rules for choosing a browsing context, then I don't immediately see how it can. If I come up with anything, I'll raise a new bug. Thanks, Bob
Sorry Ian, just noticed that the links in the table in 6.1.6 Browsing context names, still say "friends" instead of "familiar with".
Thanks, good catch.