incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: [DISCUSS] window.open target blank
Date Thu, 09 Aug 2012 19:16:47 GMT
I am good with all of that.

Can we fully document this before we jump to doing it?


On Thu, Aug 9, 2012 at 12:11 PM, Dave Johnson <dave.c.johnson@gmail.com>wrote:

> > - 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
>



-- 
@purplecabbage
risingj.com

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