Cannot close popup window after clearing opener property
Reported by
a...@scirra.com,
Jun 30 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3145.0 Safari/537.36 Steps to reproduce the problem: 1. Visit this URL: https://www.scirra.com/labs/bugs/windowcloser/ 2. Click 'Open cross-origin popup without opener' 3. Click 'Close last popup' What is the expected behavior? The popup should be closed. This works in Firefox and Edge. What went wrong? The popup is not closed and this error is logged to the console: Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://downloads.scirra.com/misc/bugs/window.html' from frame with URL 'https://www.scirra.com/labs/bugs/windowcloser/'. The frame attempting navigation is neither same-origin with the target, nor is it the target's parent or opener. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 61.0.3145.0 Channel: canary OS Version: 10.0 Flash Version: Judging by the error message, Chrome is reading the actual window.opener property, which was cleared. Presumably Firefox and Edge are storing the "real opener" separately, and testing that when checking if the window can be closed. This is important since the window.opener property has some security implications, hence the introduction of rel=noopener. If 'noopener' is specified when calling window.open(), the method returns null, so the opened window cannot be accessed at all. The workaround is to call window.open() with no location, clear its opener property, and then set its location. However this unnecessarily revokes the right to call close() in Chrome.
,
Jul 10 2017
,
Jul 10 2017
From a spec perspective, the third bullet-point in https://html.spec.whatwg.org/#familiar-with seems like the operative check, and I guess the browser behavior depends on how https://html.spec.whatwg.org/#disowned-its-opener is interpreted. If disowning the opener by setting `window.opener = null` doesn't actually clear the "opener browsing context", then the behavior you're asking for is technically correct. I'm not sure that's desirable, however: breaking the opener relationship seems like it has to be a bidirectional change. Otherwise the opened window can't defend itself against malicious behavior by its opener.
,
Jul 11 2017
The use case is to open a window with no opener, but still be able to postMessage() to it. If you want a completely isolated window, passing 'noopener' to window.open() clears the opener but the call returns null so you can't postMessage() to it. We use this in our game development PWA Construct 3 (editor.construct.net). Previewing a game runs cross-origin to the editor to ensure the game is isolated. We also want to clear the window opener, but still be able to postMessage() to initialise the game data.
,
Jul 18 2017
,
Aug 1 2017
,
Sep 4 2017
Clearing window.opener also prevents focusing the window. In other words, if a popup window clears its window.opener property to improve security, the parent window loses any ability to control it, which seems unnecessary and makes it harder to use this security feature.
,
Nov 10 2017
,
Feb 18 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by jmukthavaram@chromium.org
, Jul 5 2017Labels: M-61 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
557 KB
557 KB View Download