Agree we could use both those thins but before we solve w/ a new
nonstandard api: what doesn't work about target _blank again?
On Fri, May 18, 2012 at 7:32 PM, Andrew Lunny <alu...@gmail.com> wrote:
> Yes, a cross-platform loadUrl with some tweaks would be the right fix. The
> catch I remember with loadUrl on Android was that whitelisted URLs would
> always open in the webview - I was probably missing the openExternal option.
>
> Putting ChildBrowser in core is one long-term fix - I think a better one is
> to have a cross-platform, WebIntents style system for calling external
> services. Both are beyond the scope of this problem though, and probably
> warrant separate threads.
>
> On 18 May 2012 06:47, Bryce Curtis <curtis.br...@gmail.com> wrote:
>
>> Android has loadUrl on the App plugin that will load url into a
>> browser or same webview - depending upon a parameter. Maybe we can
>> tweak it and use as a basis for other platforms.
>>
>> /**
>> * Load the url into the webview or into new browser instance.
>> *
>> * @param url The URL to load
>> * @param props Properties that can be passed in to the activity:
>> * wait: int => wait msec before loading
>> URL
>> * loadingDialog: "Title,Message" => display a native loading
>> dialog
>> * loadUrlTimeoutValue: int => time in msec to wait
>> before triggering a timeout error
>> * clearHistory: boolean => clear webview history
>> (default=false)
>> * openExternal: boolean => open in a new browser
>> (default=false)
>> *
>> * Example:
>> * navigator.app.loadUrl("http://server/myapp/index.html";,
>> {wait:2000, loadingDialog:"Wait,Loading App", loadUrlTimeoutValue:
>> 60000});
>> */
>> loadUrl:function(url, props) {
>> exec(null, null, "App", "loadUrl", [url, props]);
>> },
>>
>>
>> On Fri, May 18, 2012 at 7:39 AM, Simon MacDonald
>> <simon.macdon...@gmail.com> wrote:
>> > 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 <alu...@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 <shaz...@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 <f...@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" <shaz...@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
>> >>> >
>> >>>
>>
