On 18 May 2012 10:48, Brian LeRoux <b...@brian.io> wrote: > Agree we could use both those thins but before we solve w/ a new > nonstandard api: what doesn't work about target _blank again? >
* not cross-platform, and will never work on Android 2 * doesn't really work on iOS - iOS can't access the value of the target attribute, so it's just checking whether "target" is set. Shaz has more details in the JIRA issue referenced above * only ever works for anchor tags - doesn't handle launching the browser on any other event > > 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 > >> >>> > > >> >>> > >> >