On Mon, Mar 10, 2014 at 2:53 PM, Paul Theriault <[email protected]>wrote:
> How about we do away with the separation between web and hosted web apps
> entirely
This is the direction I would like to see us go in too, and the system
browser in Firefox OS will go a long way towards this from a UI point of
view.
>From an architectural point of view the main difference between an "app"
and other web content is that the app content has to be loaded inside an
iframe with a manifest set in its mozapp attribute in order to get some
permissions. When loading a URL we need to know which app it belongs to in
order to know which manifest URL to set in the app window, as you describe
below.
> (unless the apps explicitly requests to be sandboxed) AFAIK, there is
> little difference in the risk profiles of web pages vs hosted apps, so
> perhaps they should all be in the same sandbox.
If by sandbox you mean they all use the same data jar, I'm not sure if
that's necessary. But I hope we can define this problem a bit better.
A. Always show browser chrome, unless you are on the origin of an installed
> app (see B though about reducing app-scope). If you are in an app, and you
> navigate to a page which is not contained within the app's scope, show
> browser chrome (unless of course you are linking to a page which is contain
> within the scope of another app).
>
Whether or not we show browser chrome is orthogonal to whether the current
URL is part of an app. Apps can request browser chrome in their manifest.
Rather than "show browser chrome" I would say "open in a browser window",
by which I mean a frame without a mozapp attribute which doesn't belong to
any other app. The browser is like a catch all for URLs which don't have
another home.
>
> B. Allow web developers to carve up their origins into web content and app
> content (potentially multiple apps), but make sure that for any given URL,
> it is either web content, or belonging to a specific app - never both, or
> multiple apps. To do this, we allow to reduce the scope of its origin in
> the manifest by supplying a URL pattern (or maybe regex even) relative to
> the origin of the manifest:
> {
> "name": "GreatApp",
> ...
> "app-scope": "/app/*"
> }
>
Yep, sounds good.
>
> We automatically fail any install if an app specifies a scope that is
> already claimed by an existing app (or ask the user if they want to
> uninstall the existing app, and replace it with the new app?)
>
That is the simplest solution.
>
> This approach also assumes one developer controls all apps on a given web
> origin. Apps on shared hosting may conflict with each other. Do we need to
> support this as a use case? Can we somehow try synthesize an app-scope
> parameter here? e.g app installed at /foo/manifest.webapp and trying to
> install /bar/manifest.webapp - we add a /foo and /bar app-scope parameter
> to each app respectively and just fail if one subsumes the other on a
> subfolder basis? (e.g if /foo/manifest.webapp, fail for attempts to install
> /foo/bar/manifest.webapp) I'm not exactly sure of the correct logic here,
> but I feel like if we are careful we can come up with a deterministic
> algorithm.
>
Alternatively we could try to use some kind of longest prefix matching and
last-registration wins like the scope of ServiceWorkers [1] I'm not sure
how well that would work.
>
> C. Hmm, maybe my approach falls down here, but if we are navigating to
> enter my google login, don't I really want to be taken out of the app, and
> into the browser view at this point? I actually hate this about other app
> platforms where you end up browsing the web inside an app.
I suggest using the "dialog" feature of window.open() for the special case
when you don't want to taken out of the app, but we should take the user
out of the app by default.
> Note that for web apps, since web apps and web content is in the same
> sandbox, we are already logged into google, just as it is on the web.
>
Yeah that is a downside of separating apps into separate data jars... you
wouldn't get that.
Allowing web apps to elect to be sandboxed:
> We should provide a option in the manifest to let sensitive apps that
> don't want to be a part of the web sandbox, hive themselves off, e.g:
> {
> "name": "GreatApp",
> ...
> "sandbox": true
> }
>
I guess that could work. Not sure whether it's necessary to be opt-in.
I haven't dealt at all with how to link to packaged apps, but that seems
> orthogonal, maybe (or at least I don't have a good answer...)
>
We can link to packaged apps, but we can't really expose those URLs to
users because they aren't real URLs. We should either give packaged apps
real URLs on the Internet, or not have packaged apps :)
Ben
1.
https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md#longest-prefix-matching
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
