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! > >> >> > >> >> > >> > > >> >
