incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: API function: Open url in system web browser
Date Fri, 18 May 2012 20:05:48 GMT
Ok! Call off the dogs. I'm genuinely looking for the reasoning not
picking a personal fight. Saying an approach is brittle and error
prone isn't useful but saying dynamic links won't work w/ the proposed
approach is very helpful. That could be a problem, tho it seems like
an edge case to me.

I'm hoping we can avoid more reverse-phonegap shims like andrews
stopgap or pats more recent browser friendly cordovajs builds.

That future, certainly does not imbue 'terror', but I do think a
solution can be done that works everywhere without introducing a new
non standard API (which is definitely error prone). The goal here is
to polyfill and remove things. Staying close to the browser.

The example code andrew gave still requires that non-standard api
which is not the solution I'm proposing. The method I'm proposing
assumes all link events are trapped, inspected for a url param, and in
its absence, falls back to default behavior. Maybe thats not
realistic. Seems like both iOS and Android do not trap the target
attribute. Which means we'd need to add a url param so that trap is
caught.

Please understand, I do not intent that ignorance to come off as an
attack on your reasoning Shaz or yours Andrew. If augmenting the links
in the page on those platforms w/ a url param is too nasty for
everyone I get it. Childbrowser seems like a more correct solution if
this is the case which I'd rather see mainlined than a new global we'd
have to back support for a year.


On Fri, May 18, 2012 at 8:36 PM, Shazron <shazron@gmail.com> wrote:
> I meant "dynamically generated anchor tags" not urls of course.
>
> On Fri, May 18, 2012 at 11:34 AM, Shazron <shazron@gmail.com> wrote:
>> I know the jira issue is mind-numbingly boring and everything but
>> please read at least my first comment in the issue. It details
>> *exactly* why "walking the dom and adding a param" won't work, because
>> of the two step process when a target attribute is set, especially if
>> it's an external url not in the whitelist (which will get rejected in
>> the first step), which we are trying to solve with loadUrl.
>>
>> Besides your method will not work with dynamically generated urls but
>> Andrew has already proposed a solution, which will need to call
>> loadUrl anyway - again, iOS the bad guy here as detailed above.
>>
>> There's no question we need an "explicit" way for users to call this
>> without implicit hackery which iOS is "trying" to do behind the
>> scenes, and failing. I realize web API purity is your goal here but it
>> won't work with how iOS handles this.
>>
>> Android has this undocumented API which we need to document anyway,
>> all we need is iOS to support it.
>>
>> +1 for loadUrl as spec'ed already by Android.
>>
>> Shaz
>>
>> On Fri, May 18, 2012 at 10:58 AM, Brian LeRoux <b@brian.io> wrote:
>>>> * not cross-platform, and will never work on Android 2
>>>
>>> why not?
>>>
>>>> * 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
>>>
>>> could we not walk the dom in the cordova.js, find elements w/ target
>>> _blank and then add a url param for ios native to intercept?
>>>
>>>> * only ever works for anchor tags - doesn't handle launching the browser
on any other event
>>>
>>> web intents things, for sure, thats a different use case / thing I think

Mime
View raw message