Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of bowserj@gmail.com designates
 209.85.223.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAM1AYQBGqUdYaHLsodK1e=VQPJZMAm7Wdoi2hqmfik1wz9Ocmg@mail.gmail.com>
References: 
 <CAE6O_-ZsorWN8Hu-d68zGMx6QQPb_Ww71q=QjWxZ_jjpsUgiuw@mail.gmail.com>
	<CAE6O_-bnZVAaMDhoA3GtEPJ3ypf_mP_vwSsu5E--=dpBzFW=_g@mail.gmail.com>
	<CABiQX1Xemk55rqEmskg4gi+7o6x8_WoyDtswY203ODgNbhEs1Q@mail.gmail.com>
	<CAE6O_-YQBL+wN2Ty_WiYJsP=-K2gySwC9yxsQN6wL8dy8vX0NA@mail.gmail.com>
	<CAE6O_-YYhEwtUQSvU1OG_83JODL6KYyxA+OuaXqh8jXtdJcfyw@mail.gmail.com>
	<CAE6O_-ZeWgK_iKvoVdCJYWFtbN+K33fQVdj6XyBQFEA2rw3Eyw@mail.gmail.com>
	<CAM1AYQBGqUdYaHLsodK1e=VQPJZMAm7Wdoi2hqmfik1wz9Ocmg@mail.gmail.com>
Date: Thu, 22 Nov 2012 11:50:44 -0800
Message-ID: 
 <CAOBL_k5072t8A3MekxqXaKfgTkKq9p5g4K_TEkrq5oJP10n_Mw@mail.gmail.com>
Subject: Re: InAppBrowser api questions
From: Joe Bowser <bowserj@gmail.com>
To: dev <dev@cordova.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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.macdonald@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 <shazron@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 <shazron@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 <shazron@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!
>> >>
>> >>
>> >
>>