incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: [DISCUSS] window.open target blank
Date Thu, 09 Aug 2012 18:49:33 GMT
?

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

Mime
View raw message