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 18:58:22 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message