incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: [DISCUSS] window.open target blank
Date Thu, 09 Aug 2012 17:59:49 GMT
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
> >>>>>
>

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