incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Johnson <dave.c.john...@gmail.com>
Subject Re: [DISCUSS] window.open target blank
Date Thu, 09 Aug 2012 19:11:48 GMT
> - is there a guarantee that the InAppBrowser is present, after all it is a
> plugin, even when it becomes a core plugin, it is still optional, isn't it?

yes that changes the options. If not present then all things that go
to InAppBrowser just go to native browser.

> - is there still an InAppBrowser api where I can actively attempt to load
> any url in the InAppBrowser? ( whether it is whitelisted or not )

sure


On Thu, Aug 9, 2012 at 11:58 AM, Jesse <purplecabbage@gmail.com> wrote:
> More than an hour to make a decision, we have been talking about this for
> months.
>
> Questions:
> - is there a guarantee that the InAppBrowser is present, after all it is a
> plugin, even when it becomes a core plugin, it is still optional, isn't it?
> - is there still an InAppBrowser api where I can actively attempt to load
> any url in the InAppBrowser? ( whether it is whitelisted or not )
>
>
>
> On Thu, Aug 9, 2012 at 11:49 AM, Brian LeRoux <b@brian.io> wrote:
>
>> ?
>>
>> On Thu, Aug 9, 2012 at 11:33 AM, Jesse <purplecabbage@gmail.com> wrote:
>> > Can we get more than an hour?
>> >
>> > On Thu, Aug 9, 2012 at 11:24 AM, Brian LeRoux <b@brian.io> wrote:
>> >
>> >> So---is this solid enough ground to open some issues / make this a part
>> of
>> >> 2.1?
>> >>
>> >> (end of september)
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Aug 9, 2012 at 10:59 AM, Michael Brooks
>> >> <michael@michaelbrooks.ca> wrote:
>> >> > Nice Dave, those conditions make sense to me.
>> >> >
>> >> > On Thu, Aug 9, 2012 at 10:54 AM, Dave Johnson <
>> dave.c.johnson@gmail.com
>> >> >wrote:
>> >> >
>> >> >> These are the window.open calls that we need to consider:
>> >> >>
>> >> >> 1) window.open('local-url.html', '_self');                    
//
>> >> >> loads in CordovaView. _parent and _top same thing
>> >> >> 2) window.open('local-url.html', '_blank');                   //
>> loads
>> >> >> in InAppBrowser
>> >> >> 3) window.open('http://whitelisted-url.com', '_self');    // loads
>> in
>> >> >> CordovaView
>> >> >> 4) window.open('http://whitelisted-url.com', '_blank');  // loads
in
>> >> >> InAppBrowser
>> >> >> 5) window.open('http://random-url.com', '_self');         // loads
>> in
>> >> >> InAppBrowser
>> >> >> 6) window.open('http://random-url.com', '_blank');      // native
>> >> browser
>> >> >>
>> >> >> window.location = 'foo' is equivalent to the '_self' options above.
>> >> >>
>> >> >> I'm operating under the assumption that local and whitelisted URLs
>> >> >> should be opened with Cordova functionality by default (_self)
and
>> you
>> >> >> have to be explicit if you want those trusted resources opened
>> without
>> >> >> Cordova functionality (_blank).
>> >> >>
>> >> >>
>> >> >> On Wed, Aug 8, 2012 at 12:13 PM, Brian LeRoux <b@brian.io>
wrote:
>> >> >> > I'd rather we continue to encourage single page apps as the
best
>> >> >> > practice for building apps w/ html, css, and js. The many
views
>> >> >> > architecture seems like it would create a strong coupling
to the
>> >> >> > native side (for transitioning esp so).
>> >> >> >
>> >> >> > I view the cleaver-ing as creating a transition path for native
>> apps
>> >> >> > to cordova apps and/or allowing the facebook/linkedin/twitter
>> webview
>> >> >> > with native chrome use case (which I do not love but understand
the
>> >> >> > desire for it in some cases).
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Aug 8, 2012 at 11:55 AM, Jesse MacFadyen
>> >> >> > <purplecabbage@gmail.com> wrote:
>> >> >> >> In the future we may want to allow multi-view apps, as
this was
>> part
>> >> >> >> of the reasoning for cleaving the view...
>> >> >> >> does this change anything?
>> >> >> >>
>> >> >> >> Cheers,
>> >> >> >>   Jesse
>> >> >> >>
>> >> >> >> Sent from my iPhone
>> >> >> >>
>> >> >> >> On 2012-08-08, at 11:28 AM, Brian LeRoux <b@brian.io>
wrote:
>> >> >> >>
>> >> >> >>> Meant to reply to this. I think Mike is correct:
>> >> >> >>>
>> >> >> >>> _blank === system browser
>> >> >> >>> _self === child browser
>> >> >> >>>
>> >> >> >>> Thoughts?
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> * * *
>> >> >> >>>
>> >> >> >>> ChildBrowser === InAppBrowser <---not perfect but
it gets rid of
>> >> >> pedobear jokes
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Tue, Aug 7, 2012 at 5:04 PM, Michael Brooks <
>> >> >> michael@michaelbrooks.ca> wrote:
>> >> >> >>>>>
>> >> >> >>>>> 2. If ChildBrowser is present, it should include
code to
>> >> >> >>>>> intercept target._blank and polyfil window.open
to its own API.
>> >> (JS
>> >> >> POC
>> >> >> >>>>> needed)
>> >> >> >>>>> 3. ChildBrowser should get an additional API
to specifically
>> >> target
>> >> >> the
>> >> >> >>>>> system default browser. ( API details TBD
)
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> Can we consider using the other anchor frame types?
[1] To me,
>> >> _blank
>> >> >> >>>> should still exit the app and open the default
browser. Perhaps
>> >> _self,
>> >> >> >>>> _parent, or _top can be intercepted to invoke
the Child Browser
>> >> (name
>> >> >> >>>> change pending)?
>> >> >> >>>>
>> >> >> >>>> - _blank: The user agent should load the designated
document in
>> a
>> >> new,
>> >> >> >>>> unnamed window.
>> >> >> >>>> - _self: The user agent should load the document
in the same
>> frame
>> >> as
>> >> >> the
>> >> >> >>>> element that refers to this target.
>> >> >> >>>> - _parent: The user agent should load the document
into the
>> >> immediate
>> >> >> >>>> FRAMESET parent of the current frame. This value
is equivalent
>> to
>> >> >> _self if
>> >> >> >>>> the current frame has no parent.
>> >> >> >>>> - _top: The user agent should load the document
into the full,
>> >> >> original
>> >> >> >>>> window (thus canceling all other frames). This
value is
>> equivalent
>> >> to
>> >> >> _self
>> >> >> >>>> if the current frame has no parent.
>> >> >> >>>>
>> >> >> >>>> [1] http://www.w3.org/TR/html401/types.html#type-frame-target
>> >> >> >>>>
>> >> >> >>>> Michael
>> >> >> >>>>
>> >> >> >>>> On Tue, Aug 7, 2012 at 4:58 PM, Jesse <purplecabbage@gmail.com>
>> >> >> wrote:
>> >> >> >>>>
>> >> >> >>>>> Brian,
>> >> >> >>>>> The ChildBrowser does NOT allow bridge access,
it is a dumb
>> view.
>> >> >> >>>>> The only way that it can communicate with
the host app is via
>> url
>> >> >> changes (
>> >> >> >>>>> a'la OAuth, NOT a'la PhoneGap gap:// commands.
)
>> >> >> >>>>>
>> >> >> >>>>> Michael,
>> >> >> >>>>> When you install a plugin, you should be aware
of what the
>> plugin
>> >> >> does.
>> >> >> >>>>> This is a developer decision and not a framework
responsibility
>> >> IMHO.
>> >> >> >>>>>
>> >> >> >>>>> ChildBrowser name suggestions? Separate thread?
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> On Tue, Aug 7, 2012 at 4:44 PM, Michael Brooks
<
>> >> >> michael@michaelbrooks.ca
>> >> >> >>>>>> wrote:
>> >> >> >>>>>
>> >> >> >>>>>> Great writeup Jesse.
>> >> >> >>>>>>
>> >> >> >>>>>> I agree with your reasoning and I like
that Child Browser is
>> not
>> >> >> ruled by
>> >> >> >>>>>> the domain whitelist.
>> >> >> >>>>>>
>> >> >> >>>>>> One concern that I have is around other
plugins. Consider the
>> >> >> scenario of
>> >> >> >>>>>> an asset downloader that may download
an archive (tar, gzip,
>> >> etc),
>> >> >> >>>>> extract
>> >> >> >>>>>> it, and inject the assets into the application's
DOM. Off the
>> top
>> >> >> of my
>> >> >> >>>>>> head, this sort of plugin should be restricted
by the domain
>> >> >> whitelist.
>> >> >> >>>>>>
>> >> >> >>>>>> Michael
>> >> >> >>>>>>
>> >> >> >>>>>> On Tue, Aug 7, 2012 at 4:30 PM, Jesse
<
>> purplecabbage@gmail.com>
>> >> >> wrote:
>> >> >> >>>>>>
>> >> >> >>>>>>> Brion:
>> >> >> >>>>>>> Yes, this should be considered part
of the API, the 'how' is
>> yet
>> >> >> to be
>> >> >> >>>>>>> defined, but apps need the ability
to specifically target
>> both
>> >> the
>> >> >> >>>>>> default
>> >> >> >>>>>>> system browser AND the ChildBrowser.
>> >> >> >>>>>>>
>> >> >> >>>>>>> ===
>> >> >> >>>>>>>
>> >> >> >>>>>>> Re: My Proposal, ( I have officially
flipped ... )
>> >> >> >>>>>>>
>> >> >> >>>>>>> After writing/sending my proposal,
I thought back to the
>> origins
>> >> >> of the
>> >> >> >>>>>>> ChildBrowser plugin.  Back when Shaz
and I wrote it some 2+
>> >> years
>> >> >> ago,
>> >> >> >>>>>> the
>> >> >> >>>>>>> goal was to allow non-secure content
to be loaded into the
>> >> >> application
>> >> >> >>>>>>> without offering any chance of the
app/dom being hijacked.
>>  At
>> >> the
>> >> >> >>>>> time,
>> >> >> >>>>>>> there was no whitelist, and all was
fine.
>> >> >> >>>>>>>
>> >> >> >>>>>>> Now that we have a whitelist, I think
we need to re-evaluate
>> >> it's
>> >> >> >>>>>> purpose.
>> >> >> >>>>>>> IMHO the ChildBrowser should NOT be
restricted to domains in
>> the
>> >> >> >>>>>>> whitelist.  If you imagine attempting
to develop a twitter
>> >> clone,
>> >> >> it
>> >> >> >>>>>> would
>> >> >> >>>>>>> be impossible to display links in
tweets unless you either,
>> >> jumped
>> >> >> out
>> >> >> >>>>> to
>> >> >> >>>>>>> the system browser, or had an allow
* in the whitelist.  IMO
>> >> this
>> >> >> is a
>> >> >> >>>>>>> perfectly valid use case for building
a phonegap app.
>> >> >> >>>>>>>
>> >> >> >>>>>>> Displaying content from ANY domain
should be a perfectly
>> >> acceptable
>> >> >> >>>>>>> practice.
>> >> >> >>>>>>> Running JS code inside the ChildBrowser
from ANY domain
>> should
>> >> be
>> >> >> >>>>>>> acceptable as well. ( XHR cross-domain
requests should
>> continue
>> >> to
>> >> >> be
>> >> >> >>>>>>> governed by the security already present
in the browser
>> control
>> >> >> itself
>> >> >> >>>>> )
>> >> >> >>>>>>> Mixing code/content from the internet
domain with the app
>> domain
>> >> >> SHOULD
>> >> >> >>>>>> be
>> >> >> >>>>>>> governed by the whitelist.
>> >> >> >>>>>>>
>> >> >> >>>>>>> The ChildBrowser already shields the
app from unsafe internet
>> >> >> code, in
>> >> >> >>>>>> that
>> >> >> >>>>>>> it does NOT allow any of the APIs
that phonegap does.  This
>> is
>> >> in
>> >> >> >>>>> harmony
>> >> >> >>>>>>> with the initial intent of the plugin,
to safely display some
>> >> >> content
>> >> >> >>>>> ...
>> >> >> >>>>>>> and not lose the app context.
>> >> >> >>>>>>>
>> >> >> >>>>>>> My adjusted proposal follows :
>> >> >> >>>>>>>
>> >> >> >>>>>>> 1. The security/whitelist checking
should be adjusted to only
>> >> >> apply to
>> >> >> >>>>>>> access attempts by the CDVViewController,
and not the entire
>> >> >> >>>>>> application. (
>> >> >> >>>>>>> not easy, I know Shaz, I can help
)
>> >> >> >>>>>>> 2. If ChildBrowser is present, it
should include code to
>> >> intercept
>> >> >> >>>>>>> target._blank and polyfil window.open
to its own API. (JS POC
>> >> >> needed)
>> >> >> >>>>>>> 3. ChildBrowser should get an additional
API to specifically
>> >> target
>> >> >> >>>>>>> the system default browser. ( API
details TBD )
>> >> >> >>>>>>>
>> >> >> >>>>>>> Cheers,
>> >> >> >>>>>>>  Jesse
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>> On Mon, Aug 6, 2012 at 4:55 PM, Brion
Vibber <
>> brion@pobox.com>
>> >> >> wrote:
>> >> >> >>>>>>>
>> >> >> >>>>>>>> On Mon, Aug 6, 2012 at 3:52 PM,
Jesse MacFadyen <
>> >> >> >>>>>> purplecabbage@gmail.com
>> >> >> >>>>>>>>> wrote:
>> >> >> >>>>>>>>
>> >> >> >>>>>>>>> [PROPOSAL]
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> 1. If a URL is not in the
whitelist, it will be passed to
>> the
>> >> >> >>>>> default
>> >> >> >>>>>>>>> system browser regardless
of any other rule. ( this will be
>> >> >> handled
>> >> >> >>>>>> on
>> >> >> >>>>>>>>> the native side, by the framework
and the JS side may not
>> even
>> >> >> know
>> >> >> >>>>>> it
>> >> >> >>>>>>>>> has happened. )
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> If the URL *is* in the whitelist,
can we send it to the
>> default
>> >> >> >>>>> system
>> >> >> >>>>>>>> browser too when calling window.open?
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> For lots of our usage at Wikimedia,
we need to whitelist
>> >> Wikipedia
>> >> >> >>>>>> sites
>> >> >> >>>>>>> in
>> >> >> >>>>>>>> order to do API calls via XHR
(at least on iOS), but also
>> want
>> >> to
>> >> >> be
>> >> >> >>>>>> able
>> >> >> >>>>>>>> to open specific pages in the
system browser.
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> 2. If ChildBrowser is present,
it should include code to
>> >> intercept
>> >> >> >>>>>>>>> target._blank and polyfil
window.open to its own API.
>> >> >> >>>>>>>>> 3. ChildBrowser should get
an additional API to
>> specifically
>> >> >> target
>> >> >> >>>>>>>>> the system default browser.
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> -- brion vibber (brion @ pobox.com
/ brion @ wikimedia.org)
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>> --
>> >> >> >>>>>>> @purplecabbage
>> >> >> >>>>>>> risingj.com
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> --
>> >> >> >>>>> @purplecabbage
>> >> >> >>>>> risingj.com
>> >> >> >>>>>
>> >> >>
>> >>
>> >
>> >
>> >
>> > --
>> > @purplecabbage
>> > risingj.com
>>
>
>
>
> --
> @purplecabbage
> risingj.com

Mime
View raw message