I have a pull request for the JavaScript changes, can someone please review: https://github.com/apache/incubator-cordova-js/pull/43
I have committed my InAppBrowser changes to iOS: https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-ios.git;a=commit;h=26a6535c To test this on iOS right now: cordova.exec(null, null, "InAppBrowser", "open", ["http://google.com";, "_blank", "location=yes"]); (don't forget to add InAppBrowser/CDVInAppBrowser to your Cordova.plist). Note that non-whitelisted URLs cannot be opened in the InAppBrowser yet because of http://issues.cordova.io/1695 which I am doing next. Once the js changes are in (at least on ios), you can do: var mywin = window.open("http://www.google.com";, "_blank", "location=no"); mywin.close(); On Thu, Nov 15, 2012 at 3:58 PM, Shazron <shaz...@gmail.com> wrote: > I updated the spec: http://wiki.apache.org/cordova/InAppBrowser > However, I added the _blank option as well just to be explicit. > > > On Thu, Nov 15, 2012 at 1:58 AM, Shazron <shaz...@gmail.com> wrote: > >> >> I spent some time playing with how to do this. >>> 1 - Use referer header - Too many situations result in no header, so this >>> is out! >>> 2 - Use Cookies - if there were a way to have UIWebViews use separate >>> cookie jars, this might be feasible. Don't think that's possible. >>> 3 - Use User-Agent - this is already suggested in CB-1695. I also found >>> this: >>> >>> http://stackoverflow.com/questions/12180224/unique-tab-id-appended-to-user-agent-string-in-chrome-for-ios >>> , >>> which suggests that this is what Chrome for iOS uses to implement >>> incognito >>> mode. If they can make it work, then we should be able to as well! >>> >>> So, this is looking like it's non-trivial but not impossible! As long as >>> it's possible, let's implement it :) >>> >>> >> Looks like it may be possible in CB-1695 as you mentioned -- so we can >> finish InAppBrowser with this one failing case until it is implemented. I >> can look into this further once I finish the InAppBrowser integration. >> >> >>> I don't think the semantics of _parent and _blank really map well to what >>> we're doing. My vote is to create a new special value: _system, and only >>> this target kicks you out to the system browser. >>> >>> Also: on the wiki we have: >>> [F] window.open('http://random-url.com', '_blank'); // native browser >>> >>> It seems weird to me that the effect of _blank changes based on whether >>> the >>> URL is in the whitelist. I'd think this case would also open in the >>> InAppBrowser. >>> >>> >>> Summary of what I think: >>> _self or no target --> open in cordova webview if it's in the Whitelist, >>> InAppBrowser otherwise >>> _system --> open in system browser >>> anything else --> open in InAppBrowser >>> >>> Also, I like Simon's idea of using the options in window.open to specify >>> whether to show URL bar etc. :) >>> >> >> I agree, we need a new value "_system" as you suggested, as well as the >> other parts of the summary of your changes -- makes more sense, and if used >> in another context -- it will just work as expected. I can make the wiki >> changes unless others have more comments. >> >> We can definitely add the window options as well, for sure! >> >> >
