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 Wed, 08 Aug 2012 19:13:11 GMT
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
View raw message