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