cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: InAppBrowser api questions
Date Thu, 15 Nov 2012 23:58:51 GMT
I updated the spec:
However, I added the _blank option as well just to be explicit.

On Thu, Nov 15, 2012 at 1:58 AM, Shazron <> wrote:

> I spent some time playing with how to do this.
>> 1 - Use referer header - Too many situations result in no header, so this
>> is out!
>> 2 - Use Cookies - if there were a way to have UIWebViews use separate
>> cookie jars, this might be feasible. Don't think that's possible.
>> 3 - Use User-Agent - this is already suggested in CB-1695. I also found
>> this:
>> ,
>> which suggests that this is what Chrome for iOS uses to implement
>> incognito
>> mode. If they can make it work, then we should be able to as well!
>> So, this is looking like it's non-trivial but not impossible! As long as
>> it's possible, let's implement it :)
> Looks like it may be possible in CB-1695 as you mentioned -- so we can
> finish InAppBrowser with this one failing case until it is implemented. I
> can look into this further once I finish the InAppBrowser integration.
>> I don't think the semantics of _parent and _blank really map well to what
>>  we're doing. My vote is to create a new special value: _system, and only
>> this target kicks you out to the system browser.
>> Also: on the wiki we have:
>> [F]'', '_blank'); // native browser
>> It seems weird to me that the effect of _blank changes based on whether
>> the
>> URL is in the whitelist. I'd think this case would also open in the
>> InAppBrowser.
>> Summary of what I think:
>> _self or no target --> open in cordova webview if it's in the Whitelist,
>> InAppBrowser otherwise
>> _system --> open in system browser
>> anything else --> open in InAppBrowser
>> Also, I like Simon's idea of using the options in to specify
>> whether to show URL bar etc. :)
> I agree, we need a new value "_system" as you suggested, as well as the
> other parts of the summary of your changes -- makes more sense, and if used
> in another context -- it will just work as expected. I can make the wiki
> changes unless others have more comments.
> We can definitely add the window options as well, for sure!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message