Eh Simon, was just trying to kick the tires using the wiki test page [1] but always only loads in the webview for me atm. I'm certain I missed something simple---all I did was create a default project---anything immediately occur that I might be missing?
[1] http://wiki.apache.org/cordova/InAppBrowserTest On Thu, Nov 22, 2012 at 9:30 PM, Simon MacDonald <simon.macdon...@gmail.com>wrote: > Well, I've got the code mostly implemented there are some things that > probably can be thrown away or cleaned up a bit (UI, events). I'll probably > push a version later tonight. All of the manual mobile spec tests are > working for me. > > With regards to the back button, if clicked it closes the InAppBrowser. Why > you ask? Well the implementation of the ChildBrowser had a hide navigation > bar parameter and if it was hidden there was no way to dismiss the dialog. > That's why I'm asking some UI questions as things will need to change just > a bit. > > Simon Mac Donald > http://hi.im/simonmacdonald > > > On Thu, Nov 22, 2012 at 2:50 PM, Joe Bowser <bows...@gmail.com> wrote: > > > Why do we have the Forward and Back buttons on the browser on Android > > when Chrome and the Default Browser only have a refresh button? How > > does this handle the hardware back button? I think we should do what > > the platform does, except that we don't need multi-tab browsing. > > > > On Thu, Nov 22, 2012 at 11:47 AM, Simon MacDonald > > <simon.macdon...@gmail.com> wrote: > > > Should the implementation of the InAppBrowser on Android mimic the UI > of > > > the iOS app or should it go it's own way? > > > > > > Currently the Android ChildBrowser has the buttons and location bar on > > the > > > top of the screen. Is there any UI pattern we should be following for > > this > > > type of in app browsing? > > > > > > Simon Mac Donald > > > http://hi.im/simonmacdonald > > > > > > > > > On Mon, Nov 19, 2012 at 6:24 PM, Shazron <shaz...@gmail.com> wrote: > > > > > >> 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! > > >> >> > > >> >> > > >> > > > >> > > >
