Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of simon.macdonald@gmail.com
 designates 209.85.210.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPihERRnzcL0FKH2xchGxjFv=O5891762yDwq2Z_ZJmHyNeC=w@mail.gmail.com>
References: 
 <CAE6O_-YUy89+hSQO+8g=1BZNm=tC+m_2ksd8xAqB17aWic6BLQ@mail.gmail.com>
 <CBDABB43.6740%fil@adobe.com>
 <CAE6O_-bjd1WBTukiTJY-gSXFYTKMKY96zh=Ko7nGJpFL0obYcA@mail.gmail.com>
 <CAPihERRnzcL0FKH2xchGxjFv=O5891762yDwq2Z_ZJmHyNeC=w@mail.gmail.com>
From: Simon MacDonald <simon.macdonald@gmail.com>
Date: Fri, 18 May 2012 08:39:02 -0400
Message-ID: 
 <CAM1AYQD2fHjrEoiEHMUK3SC=YHLjz6ib6rWnqCA461O1EexBdQ@mail.gmail.com>
Subject: Re: API function: Open url in system web browser
To: callback-dev@incubator.apache.org, alunny@gmail.com
Content-Type: text/plain; charset=ISO-8859-1

Maybe it's time to pull the ChildBrowser into the core Cordova API? It
is currently available on Android/BB/iOS (not sure about WP7). This
seems like the logical place to put any new API. Specifically on
Android the ChildBrowser gives you two main methods:

showWebPage - communicates with your main app by sending location change events.
openExternal - Fires up the native Android browser

Simon Mac Donald
http://hi.im/simonmacdonald


On Thu, May 17, 2012 at 6:12 PM, Andrew Lunny <alunny@gmail.com> wrote:
> Why would a new API be overkill for something tons of apps and users
> need? Here are some representative threads from PG Build about users
> wanting this kind of API:
>
> http://community.phonegap.com/nitobi/topics/external_links_outside_webview
> http://community.phonegap.com/nitobi/topics/iframes_open_in_safari_in_ios
> http://community.phonegap.com/nitobi/topics/why_app_opens_in_external_widow
> http://community.phonegap.com/nitobi/topics/opening_native_browser_programmatically_with_phonegap_build
> http://community.phonegap.com/nitobi/topics/js_opening_links_methods_and_config_xml_access_tag
>
> I realize a few of those were started by the same user, but there are lots
> of me-toos and responses.
>
> -1 on clobbering window.open. window.open takes 3 parameters, two of which
> are invalid for this use case, and lacks a callback parameter (for example,
> if the user is prompted with a choice of browsers on an Android device and
> declines to open the link entirely).
>
> On 17 May 2012 14:27, Shazron <shazron@gmail.com> wrote:
>
>> iOS doesn't differentiate what the target attribute value is (thus
>> ambiguous in Objective-C what the intent is).
>>
>> Good idea - we could clobber window.open, sure - and we add the native
>> bits to support this.
>>
>> On Thu, May 17, 2012 at 2:27 PM, Filip Maj <fil@adobe.com> wrote:
>> > So target="_blank" is no good to use for this.
>> >
>> > A "new" API seems overkill for me.
>> >
>> > What about clobbering window.open ?
>> >
>> > On 5/17/12 2:19 PM, "Shazron" <shazron@gmail.com> wrote:
>> >
>> >>Punted this too much, need all of your input on this.
>> >>
>> >>Summary:
>> >>We need an API function on all platforms to always open a url in the
>> >>system web browser, right now each platform does its own thing, and on
>> >>iOS it is very wonky, relying on a something that is ambiguous
>> >>(navigation type value) through the target attribute of an anchor tag.
>> >>Basically, I agree with Andrew's proposal here:
>> >>
>> https://issues.apache.org/jira/browse/CB-362?focusedCommentId=13247777&pag
>>
>> >>e=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment
>> >>-13247777
>> >>
>> >>
>> >>JIRA issue:
>> >>https://issues.apache.org/jira/browse/CB-362
>> >>
>> >>See the matrix in the PG Build blog post:
>> >>https://build.phonegap.com/blog/access-tags
>> >
>>