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