New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 136610 link

Starred by 121 users

Issue metadata

Status: Fixed
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
Pri: 2
Type: Compat

Blocked on:
issue 423444

issue 493419

  • Only users with EditIssue permission may comment.

Sign in to add a comment

windows from do not have window.opener property

Reported by, Jul 10 2012

Issue description

Chrome Version (from "Settings > About Google Chrome"): 19.0.1084.60
Device Type: iPad 3
URLs (if applicable):

Behavior in Safari (if applicable):
New windows opened in Safari have access to window.opener

Steps to reproduce:
1. In a tab, open a page that runs the code `var w =, null, null);
2. The page at yourURL should try to access `window.opener`, such as to postMessage back to the original page
3. Don't profit.

Expected result:
New window can access window.opener.

Actual result:
window.opener is undefined.

Labels: Area-Internals Type-Bug
Status: Untriaged

Comment 2 by, Jul 11 2012

Would allow BrowserId to work.

Our app is currently broken in Chrome for iOS because of this one :(
Status: ExternalDependency
Our reference b/6802841
Yup, very problematic as BrowserId can't work (or any other stuff relying on relay frames, like facebook connect etc.).
Any hope this will get touched?
It's on our radar, but handling generic inter-window JS via UIWebView is not a simple problem.
 Issue 162383  has been merged into this issue.

Comment 8 Deleted

Comment 9 by Deleted ...@, Feb 1 2013

Any news on possible fixes for window.opener?
you should realize ha most of the apps and webs sites dealig with login via faceook linkedin, tweeter etc depend on windo.opener functionalty
and so chrome  for ios could not be used at all simply because users can't propertly login.
Safari for IOS handle with with out any issues so im not sure why crome can't.
It's bben more than half a year since this bug been reported with no progress whats so ever ;(
Yes, we are all waiting on this. However, there are some workarounds. 

JS Overlay and Getting Session Variable

Basically, when the user clicks/touches to leave for oauth, you create an overlay on your app. After user authenticates through oauth and is returned to the callback, the callback url will store somekind of user flag in session and close the window. Now when the user returns to the application, an overlay will be active. The overlay will cause the user to tap or interact with it. Upon interaction, you'll call upon JS to get the session flag and close the overlay. 

Not perfect but a fit all solution.
> Any news on possible fixes for window.opener?

No. If there changes to this bug's status, you'd see them in the bug.

> you should realize ha most of the apps and webs sites dealig with login
> via faceook linkedin, tweeter etc depend on windo.opener functionalty

We do.

> Safari for IOS handle with with out any issues so im not sure why crome can't.

Safari is not limited by App Store rules the way all third-party apps are. Apple can use any WebKit APIs they want to, whereas we are constrained to what is possible using UIWebView.

> It's bben more than half a year since this bug been reported with
> no progress whats so ever ;(

Wanting to fix something and having the power to fix something are not the same thing when operating in a development environment with significant artificial constraints imposed on it. Complaining here won't have any impact on Apple's policies.

We understand the importance of this issue; posting here won't cause it to be fixed faster. Please just star the bug to get updates if/when we find a way to support this, instead of spamming everyone else who is following the bug.

Comment 12 Deleted

Project Member

Comment 13 by, Mar 10 2013

Labels: -Area-Internals Cr-Internals
Is there an example of the workaround available anywhere?

Comment 15 Deleted

Comment 16 by, Apr 17 2013

Is there any update to this bug? Unfortunately this also prevents postMessage from working inter-window, and thus breaks a number of OAuth flows (Twitter/Facebook).
You may try to not open new window for authentication, but use current window and pass redirect url of page, where user was before

Comment 18 by, Apr 19 2013

#17 That's not a good solution. It destroys state. It's useless for what we (Stripe) need, and wouldn't work for the popup oauth flows either.

Comment 19 Deleted

Comment 20 by, Apr 20 2013

I ran into this problem close to when it was reported when I was working on oauth flows. Got around it by using localstorage. I would store the values I need on localstorage in the child window and immediately close it on oauth success flow. And the parent window would be set up to poll localstorage for that value to be set. As long you clean up after yourself, this worked well for us.  

Comment 21 by Deleted ...@, Apr 26 2013

#20 I also recommend the localstorage method as a workaround for cross-window communication. To ensure proper setup/cleanup around the polling, we ( ended up having two keys that we set in localstorage, one as a "ready" flag that got set when the listener setup up the message queue and removed in the onunload event, and the other being the message queue.
can someone post here the workaround code. It would be of great help.

Comment 23 Deleted

How? We still don't have a way to link the two JS contexts between UIWebViews that know nothing about each other.

Comment 26 Deleted

I was thinking that via the Objective-C / JavaScript bridge, calls to window.opener could be mapped to native methods which communicate with the original window, again via the bridge.

Similar to what's been demonstrated in the README here:
Communicating between JS and ObjC (which is the part that library handles) is only a small part of the problem. Realtime synchronization of proxy objects with JS state is infeasible, synchronous calls have potential re-entry issues in UIWebView, and many uses of window.opener (e.g., auth flows, as mentioned above) need complex frame/window interactions involving different origins that are broken when the only place JS can be run in is the top-level window.

Comment 29 Deleted

Comment 30 Deleted

Comment 31 Deleted

Comment 32 Deleted

Comment 33 Deleted

Labels: -Cr-Internals Cr-Internals-Mobile-Web
Regarding #20 and #21, I tried to patch this using localStorage and a setInterval function in the opener that checks if the localStorage item has been updated and the child window has been closed. Until now, no luck. It would be really helpful if you can post your workaround. Thanks in advance.

Comment 36 by, Oct 3 2013

I've solved this using local storage as a backup in case window.opener doesn't work. Thank you #20 for the suggestion.

It's not a working jsfiddle, but the code needed is there so I hope you can work it out too. It works great and I dont have any problem with non Safari browsers on iOS anymore.

Comment 37 by Deleted ...@, Jan 7 2014

Just curious if there's any update on this or timeline of when a fix might be released? Definitely disheartening to have rewrite oauth flows for this one browser
> Just curious if there's any update on this or timeline of when a fix might be released?

Please see comments 11 and 28, which continue to be true.

Comment 40 by Deleted ...@, Jan 17 2014

Our browsers have the window.opener locked out for security purposes.  I like your approach but can't seem to get it to work.  I need to display a popup window which has several choices to display different images (of different sizes).  If I could pass that image back to the parent and redisplay it using your callback function that would seem to work.  Also wasn't quite sure about the placement of your popupCenter function.  Thanks in advance.

Comment 41 by, Jan 19 2014

The key thing here is that you CAN'T use window.opener. That's why you have to have a backup plan using the local storage. The window.opener was in my code example becuase this is what most browsers will use, the local storage is just the backup..

1. Start a timer which will check storage parameter "x" every 100 ms
2. Open up the popup.
3. The user clicks a button for example. Now set the "x" parameter to "true" or something or maybe your image path.
4. The timer finds out the "x" variable is set... Stop the timer, and do whatever you like with the information in "x".
I understand the desire to discuss workarounds, but this is really not the place for it. If someone wants to post something on a discussion or Q&A forum like StackOverflow and link to it from here, that's fine, but back and forth about the details of how to work around this on the site don't belong in this bug, which is for tracking work in Chrome.
Ok, so what can we as developers do to make Apple correct whatever it needs to correct on UIWebView to make this work? Is there a bug report somewhere? How can we help?
You can't *make* Apple do anything, but anyone affected by this can file a bug against Apple about the fact that UIWebView doesn't support and subsequent cross-site scripting, to clearly communicate demand for that support.

There's no way for people to add votes or comments to existing Apple bug reports, so the usual advice is for everyone to file their own.

Comment 45 Deleted

Comment 46 Deleted

OK, so here's the URL for bug reporting in Apple: I created a bug report with the information contained in this issue.
I encourage everyone who has stared this issue to do the same.

Comment 48 by, Jan 30 2014

Could you link us to the report you filed so we can follow your template?
I don't think there's a way to link the report, but I can paste the content here:

Marcos Jose Chicote29-Jan-2014 03:37 PM

Please add support for and subsequent cross-site scripting to UIWebView. This is blocking Facebook/Twitter/etc login workflows in Chrome for iOS for example

Steps to Reproduce:
1. In a tab, open a page that runs the code `var w =, null, null);
2. The page at yourURL should try to access `window.opener`, such as to postMessage back to the original page
3. Don't profit.

Expected Results:
New window can access window.opener.

Actual Results:
window.opener is undefined.



Chrome Version (from "Settings > About Google Chrome"): 19.0.1084.60
Device Type: iPad 3


Comment 50 Deleted

Comment 51 Deleted

 Issue 341984  has been merged into this issue.
Labels: -Cr-Internals-Mobile-Web Cr-Mobile-WebView-Glue

Comment 54 Deleted

Comment 55 Deleted

Comment 56 Deleted

Labels: M-36
Status: Fixed

Comment 58 Deleted

Comment 59 Deleted

Comment 60 Deleted

Comment 61 Deleted

Comment 62 Deleted

Comment 63 by Deleted ...@, Jul 17 2014

Today I updated Chrome on my iPad (iOS 7.1.2) to 36.0.1985.49, and I'm still having this problem.

1) Set up weinre on a debug computer
2) Open a Test Page A in Chrome
3) From Test Page A, spawn another Test Page B with
4) Connect to Test Page B with weinre
5) in weinre, check value of window.opener
EXPECTED RESULT:  window object of Test Page A
+1. I am also still seeing this issue on Chrome v36.0.1985.49 on iPhone v7.1.2.
Labels: ReleaseBlock-Respin
Status: Assigned
Thanks folks, we'll take a look.
Regular calls of work if they triggered by user-gesture.
The following cases are not implemented:
  popups: calling from setTimeout()
  locating existing window by name:"javascript:void(0);", existingWindowName)

If your case is not popup-related, please provide a link to sample web site where we can reproduce the issue.

Comment 67 by Deleted ...@, Jul 17 2014

What counts as a user-gesture?

We have an onclick handler which calls `, popupName, opts, false);`

For Chrome, opts is an empty string '', but on other browsers we pass some options in.

I don't have a public repro of the issue, but would be happy to provide the Chromium team w/ a temporary demo login to our dev server, demonstrating the issue.
If user clicks/taps the following button: '<button onclick="">Click!</button>' it means that was invoked by user gesture. If was called via setTimeout call it's a popup. And we don't support window.opener for popups.

Regarding your sample code and in particular popupName (target) parameter. We don't support window.opener if target param was other than undefined, '_blank', '' or null. 

Comment 69 by Deleted ...@, Jul 18 2014

Thanks @eugene, making popupName '_blank' solved the problem for us.
Changing window name to "_blank" also worked for me, Eugene. Thank you very much.
The pop-up from the Google+ Javascript API log in button still does not work for me.
Google+ login flow is not supported yet.

Comment 73 Deleted

Comment 74 Deleted

Comment 75 Deleted

Comment 76 Deleted

Comment 77 Deleted

Comment 78 Deleted

Comment 79 Deleted

Comment 80 Deleted

Comment 81 Deleted

Comment 82 Deleted

Comment 83 Deleted

Comment 84 Deleted

Comment 85 Deleted

Comment 86 Deleted

Labels: Restrict-AddIssueComment-EditIssue
Please see comment 42. Again, this is not the appropriate place to try to get workarounds.

This bug has gotten very long and very confusing, and questions that have already been answered earlier are getting re-asked; I'm going to lock it to prevent it from continuing to get sidetracked into specific cases (and remove some of the comments that are not generally applicable).
- If you are trying to figure out the limitations of Chrome on iOS with respect to window.opener, see comment 66 and comment 68.
- If you have a case that does not work and is not covered by comment 66/68, please file a new bug *with a test case* and refer to this bug.
- If you want to be updated if there are any changes, star the bug.

(And if you want to point out that it's possible to fully implement this using WKWebView instead of UIWebView for iOS 8+, we're aware of that, but WKWebView is not a drop-in replacement; it's certainly being evaluated though).
Labels: -M-36 -ReleaseBlock-Respin
Labels: -Type-Bug Type-Compat
 Issue 450955  has been merged into this issue.
Issue 228366 has been merged into this issue.
 Issue 163443  has been merged into this issue.

Comment 93 by, May 7 2015

 Issue 142899  has been merged into this issue.
Blocking: chromium:493419
Blockedon: chromium:423444 will be fully functioning after switching Chrome for iOS to WKWebView: 
Labels: Hotlist-FixedByWKWebView
Labels: M-48
Status: Fixed
Closing, as this is fixed in M48 by the switch to WKWebView ( bug 423444 )

Sign in to add a comment