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 19:44:39 GMT
started a wiki page to document; no one has to jump into doing
anything until comfortable (obviously?)

http://wiki.apache.org/cordova/InAppBrowser



On Thu, Aug 9, 2012 at 12:16 PM, Jesse <purplecabbage@gmail.com> wrote:
> 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
View raw message