Would allow BrowserId to work.

Our app is currently broken in Chrome for iOS because of this one :(

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.

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.

Is there an example of the workaround available anywhere?

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

#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.

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.  

#20 I also recommend the localstorage method as a workaround for cross-window communication. To ensure proper setup/cleanup around the polling, we (Filepicker.io) 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.

Seems like this will really help: http://www.steamclock.com/blog/2013/05/apple-objective-c-javascript-bridge/

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

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: https://github.com/BeamApp/Transit

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.

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.

#35
I've solved this using local storage as a backup in case window.opener doesn't work. Thank you #20 for the suggestion.
See: http://jsfiddle.net/QpQWj/1/

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.

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.

#36
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.

#40
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 window.open 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.

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

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

Summary:
Please add support for window.open 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 = window.open(yourURL, 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.

Version:
7.0.4

Notes:


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

Attachments:

 Issue 341984  has been merged into this issue.

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 window.open()
4) Connect to Test Page B with weinre
5) in weinre, check value of window.opener
EXPECTED RESULT:  window object of Test Page A
ACTUAL RESULT: null

+1. I am also still seeing this issue on Chrome v36.0.1985.49 on iPhone v7.1.2.

Thanks folks, we'll take a look.

Regular calls of window.open() work if they triggered by user-gesture.
The following cases are not implemented:
  popups: calling window.open from setTimeout()
  locating existing window by name: window.open("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.

What counts as a user-gesture?

We have an onclick handler which calls `window.open(url, 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="window.open(url)">Click!</button>' it means that window.open was invoked by user gesture. If window.open 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. 

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.

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).

 Issue 450955  has been merged into this issue.

Issue 228366 has been merged into this issue.

 Issue 163443  has been merged into this issue.

 Issue 142899  has been merged into this issue.

window.open will be fully functioning after switching Chrome for iOS to WKWebView:  crbug.com/423444 

Closing, as this is fixed in M48 by the switch to WKWebView ( bug 423444 )