incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: API function: Open url in system web browser
Date Sun, 20 May 2012 02:43:22 GMT
No. Read it again, especially the two request part. For urls NOT in
the whitelist, the first request will be rejected by the whitelist. It
won't work.

On Sat, May 19, 2012 at 7:34 PM, Brian LeRoux <> wrote:
> Ok, so read that, its referring to the target attribute but it looks
> like you can check stil check for a url parameter on an NSURLRequest
> [1].
> So what I'm proposing is this: cordovajs walks the dom finding all
> anchors with a target attribute and adds something like this to the
> href:
> <a href= target=blank>asdf<.a>
> Then, when clicked, touched, whatever, you capture if the URL
> parameter named _cordova-target exists. If it does, spawn browser.
> Dynamic links would be missed. I think thats an ok/fair quirk. If
> wanted to be aggressive we *could* watch for dom mutation events and
> solve that too tho I suspect it would not help performance!
> On Sat, May 19, 2012 at 6:00 PM, Shazron <> wrote:
>> When JIRA is back up (it's under maintenance right now), see my
>> first/second comment on this issue:
>> It's a bit too long to rehash :)
>> On Sat, May 19, 2012 at 8:17 AM, Brian LeRoux <> wrote:
>>> Sorry shaz, I must be dense but I missed the technical reasons?
>>>  On May 19, 2012 11:48 AM, "Shazron" <> wrote:
>>>> > The method I'm proposing
>>>> > assumes all link events are trapped, inspected for a url param, and
>>>> > 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.
>>>> >
>>>> It is not entirely a question of "nastiness" in adding a url param
>>>> with regards to why it won't work in iOS (although imo I don't like
>>>> it) - I have already presented valid technical reasons.
>>>> With respect to achieving all our goals - not introducing a new API,
>>>> and fixing this bug that sorely needs fixing - ChildBrowser like you
>>>> proposed is the better bet then. So what should be the plan for this?

View raw message