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 <[email protected]> wrote: > I meant "dynamically generated anchor tags" not urls of course. > > On Fri, May 18, 2012 at 11:34 AM, Shazron <[email protected]> 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 <[email protected]> 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
