incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse MacFadyen <purplecabb...@gmail.com>
Subject Re: [DISCUSS] window.open target blank
Date Wed, 08 Aug 2012 18:55:26 GMT
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