Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Sort out window.opener behavior when a window.open with target targets an existing window #2636

Closed
bzbarsky opened this issue May 5, 2017 · 10 comments
Closed

Sort out window.opener behavior when a window.open with target targets an existing window #2636

bzbarsky opened this issue May 5, 2017 · 10 comments
Labels
topic: browsing context

Comments

@bzbarsky
Copy link
Contributor

bzbarsky commented May 5, 2017

Per spec, unless pages set window.opener it should only return non-null for auxiliary browsing contexts and should be immutable on auxiliary browsing contexts.

Here are some testcases for what browsers actually do. First:

<!DOCTYPE html>
<input type="button" onclick="alert(opener + ' ' + (opener == window))" value="check opener">
<input type="button" onclick="window.open(location.href, '_self')" value="do open">

Load it in a new window you open from the browser UI, click the "check opener" button, click the "do open" button, click the "check opener" button. Per spec it should alert "null false" both times. In Firefox, Chrome, and Safari the second alert does NOT alert "null false" and instead alerts "[object Window] true". In Edge both alerts alert "undefined false". Live testcase at http://web.mit.edu/bzbarsky/www/testcases/window-opener/open-targeting-self.html

Second:

<!DOCTYPE html>
<iframe src="open-targeting-self.html"></iframe>

where open-targeting-self.html is the document from the first testcase. Behavior is the same as for the first testcase. So it's not a matter of opener only getting dynamically updated for toplevel windows; we can get nested browsing contexts which claim to have an opener in Firefox, Chrome, and Safari. Live testcase at http://web.mit.edu/bzbarsky/www/testcases/window-opener/open-targeting-subframe.html

Third:

<!DOCTYPE html>
<input type="button" onclick="window.open('open-targeting-self.html', '_blank')" value="do open">

Click the "do open" link, then follow the steps from the first testcase in the resulting window. Per spec, second alert should be "[object Window] false" but it's "[object Window] true" in Firefox, Chrome, and Safari. Live testcase at http://web.mit.edu/bzbarsky/www/testcases/window-opener/open-targeting-new.html

I'm pretty worried about compat fallout from trying to do the spec behavior here.
@bzbarsky bzbarsky mentioned this issue May 5, 2017
Merged
@bzbarsky
Copy link
Contributor Author

bzbarsky commented May 5, 2017

I'm pretty sure that Gecko just unconditionally sets .opener when window.open targets an existing window, but it looks like Blink and WebKit does something slightly different, given that http://w3c-test.org/html/browsers/windows/browsing-context-names/choose-_parent-003.html manages to pass there.

@RByers do you know who would know what the actual Chrome behavior is here?

@RByers
Copy link

RByers commented May 5, 2017

Hmm, not sure offhand. @foolip @dominiccooney any ideas who might know or could dig into this?

@bzbarsky
Copy link
Contributor Author

bzbarsky commented May 6, 2017

I did try poking through code myself a bit, but got slightly lost in all the virtual SetOpener overloads and such. ;)

@annevk
Copy link
Member

annevk commented May 9, 2017

@bzbarsky should setting opener to null for the non-top-level-browsing-context cases affect link targeting (#313)?

@bzbarsky
Copy link
Contributor Author

bzbarsky commented May 9, 2017

should setting opener to null for the non-top-level-browsing-context cases affect link targeting

Probably not, though I have no idea what browsers actually do in practice. :(

@annevk
Copy link
Member

annevk commented Jan 23, 2019

This seems to be special to window.open():

<iframe name=test></iframe>
<a href=frame.html target=test>a</a>
<a onclick="window.open('frame.html', 'test')">window.open</a>

Only the window.open link will give the frame a non-null self.opener. Once it has one, it'll keep it though, so it's stored on the browsing context somehow. And it'll have to be triggered from window.open() only somehow.

This probably needs to be solved together with #313 (comment) to see if "disowning" is limited to auxiliary browsing contexts or not.

@annevk
Copy link
Member

annevk commented Jan 23, 2019

If I make popup.html set self.opener to null it doesn't change anything. Setting self.name to "different" will make the next click open a "popup", however. I strongly suspect disowning is limited to the auxiliary browsing context therefore.

@bzbarsky
Copy link
Contributor Author

This seems to be special to window.open()

I think some browsers have recently changed, or considered changing, whether targeted <a> sets opener on the result (even when creating a new auxiliary browsing context?). I don't know what the exact behavior is across browsers nowadays....

@annevk
Copy link
Member

annevk commented Jan 24, 2019

That's #4078 I hope, which affects _blank and we'll standardize in due course (provided the experiment works out).

@annevk annevk mentioned this issue Jan 24, 2019
Merged
@bzbarsky
Copy link
Contributor Author

That's #4078 I hope

That's part of it, but I thought there was some discussion about whether targeted <a> should set opener at all, ever. I may be imagining it, though...

@annevk annevk closed this as completed in a48895e Jan 29, 2019
mustaqahmed pushed a commit to mustaqahmed/html that referenced this issue Feb 15, 2019
@annevk @mustaqahmed
Refactor browsing context creation
d4b1e3d 
Some initial work to make introducing browsing context groups (see whatwg#4198) easier.

Fixes whatwg#2636 by making opener browsing context more generally applicable and making window.open() set it.

Fixes whatwg#2645 by removing creator browsing context and explicitly passing in the creator document.

Tests: web-platform-tests/wpt#15078.
mustaqahmed pushed a commit to mustaqahmed/html that referenced this issue Feb 15, 2019
@annevk @mustaqahmed
Refactor browsing context creation
c375277 
Some initial work to make introducing browsing context groups (see whatwg#4198) easier.

Fixes whatwg#2636 by making opener browsing context more generally applicable and making window.open() set it.

Fixes whatwg#2645 by removing creator browsing context and explicitly passing in the creator document.

Tests: web-platform-tests/wpt#15078.
@annevk annevk mentioned this issue May 21, 2020
Closed
@pascoej pascoej mentioned this issue Jun 27, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: browsing context
Milestone
No milestone
Development

No branches or pull requests
3 participants
@RByers @bzbarsky @annevk