W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [manifest] Update and call for review

From: Ben Francis <bfrancis@mozilla.com>
Date: Tue, 27 May 2014 14:19:44 +0100
Message-ID: <CADKQpGSGsHWhwPf48du3xbr=oU=_tmY3PJ+D1=fs-zeEuTzkeA@mail.gmail.com>
To: Marcos Caceres <w3c@marcosc.com>
Cc: public-webapps <public-webapps@w3.org>
On Mon, May 26, 2014 at 8:18 PM, Marcos Caceres <w3c@marcosc.com> wrote:

> Quick update: the Editors have closed off all "V1" bugs for [manifest] and
> implementations in Blink and Gecko are underway. A thorough review of
> [manifest] by interested parties would be greatly appreciated! You can file
> bugs in our GitHub [bug tracker].

Nice work! FYI I expect implementation in the Firefox OS browser to be
tracked here https://bugzilla.mozilla.org/show_bug.cgi?id=1003890

> We now have the option to cherry-pick V2 features to either spin off into
> separate specs or to add to the current document. You can view the V2
> features at [V2]. See also the [CSP-member], which is already in its own
> spec.
> Devs and implementers, please let us know which V2 features should be
> prioritized.

To me the biggest issues for v2 are:

URL Scope to which the manifest applies

Specify how navigation works

....which I think are all part of the same issue of "app scope".

The specification describes a manifest whose properties can be used when
bookmarking a web app and effect how that bookmark should be displayed by
the user agent when it is launched (e.g. in a standalone window in
landscape orientation with no navigation controls). But it does not specify
the URL scope to which those properties apply. For example, what display
mode the user agent should use when the browsing context is navigated away
from the start_url, or away from the origin entirely to another unrelated
web site.

In other words, what is the scope of the app?

All the specification has to say on this topic is "The user agent MAY
override the default display mode for security reasons (e.g., the top-level
browsing context is navigated to another origin)". But this doesn't include
navigational reasons (e.g. getting stranded on another web site without a
back button) or the case of multiple origins per app or multiple apps per

In Firefox OS the user can get stranded by following a hyperlink from an
installed app to an off-origin web page with no back button and no
indication that they have left the origin.

Chrome for Android will show the new origin at the top of the screen if you
navigate outside the origin in a "mobile-web-app-capable" homescreen
bookmark, but it won't provide browser chrome.

In Chrome OS if you open the Google search app as a window and click on a
search result, it will navigate you to the result web page but not provide
any browser chrome for the web site.

I think a particular problem with having no defined scope for apps is when
you want to hyperlink from one web app to another. A hyperlink with no
specified target window will always open in the browsing context of the
current app, regardless of whether the URL belongs to another app or web
site. That means that the level of browser chrome you get when following a
hyperlink (as well as the orientation of the page and the title and icon
shown in the task switcher etc.) depends on where you navigated from rather
than where you navigated to.

I would like to see some way to define the scope to which an app manifest
applies, so that the user agent knows which URLs belong to which apps and
therefore what display properties to use for a given URL.
Received on Wednesday, 28 May 2014 08:21:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC