incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [DISCUSS] window.open target blank
Date Thu, 09 Aug 2012 22:02:01 GMT
I'll add a task in JIRA - with sub-tasks for the diff platforms (will
start with Android and iOS)

On Thu, Aug 9, 2012 at 12:44 PM, Brian LeRoux <b@brian.io> wrote:
> 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