1038833 - [Meta] App Scope

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[:Harald Kirschner :digitarald]

Track the implementation of URL Scope for apps.

Comment 1

[Ben Francis [:benfrancis]]

Once App Scope has been added to the app manifest, we need to respect it in Gaia. Adding some dependencies for doing that. Feel free to unblock if you'd rather just track the apps API work.

Comment 2

[Ben Francis [:benfrancis]]

Note that some of that work is being tracked on the Browser API roadmap https://wiki.mozilla.org/WebAPI/BrowserAPI

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I posted a detailed proposal to dev-b2g.

https://groups.google.com/forum/#!topic/mozilla.dev.b2g/Ufrz9UW-Z28

Comment 4

[Bill Walker [:bwalker] [@wfwalker]]

Sandip, how can we nominate this as a b2g 2.2 feature?

Comment 5

[Ben Francis [:benfrancis]]

Please note the brief explanation of "scope" in the Web Manifest explainer on HTML5 doctor, the scope property is expected in an upcoming editor's draft of the spec http://html5doctor.com/web-manifest-specification/

Comment 6

[Ben Francis [:benfrancis]]

There is a proposal over at https://github.com/w3c/manifest/issues/114 for what the default value of "scope" should be for the W3C Web Manifest. It would be nice if Open Web Apps could have a scope property compatible with the W3C proposal, but that might be problematic.

The proposal is that if no scope property is provided then the default scope should be the start_url (equivalent of launch_path) and if no start_url is provided then the bookmarked URL should be the scope. This may work OK for Web Manifest in a lot of cases, but it might not be a great default for some common cases and it isn't very backwards compatible with some existing apps in the Firefox Marketplace.

As far as I know we don't record the URL an app was installed from because in many cases that will be a page in the Marketplace which wouldn't make a very good URL scope for the app. The launch_path property for Open Web Apps defaults to the root of the origin, which is inconsistent with the W3C proposal. If a launch_path of "/index.html" was defined it would be used as the default scope if not scope property is defined, but that would make a resource at /foo out of scope of the app which seems wrong.

Here are some examples of apps in the Marketplace which might exhibit unexpected behaviour if we implemented App Scope in Open Web Apps the way it has been proposed for Web Manifest:
* MessageMe (no. 3 most popular app) - Gives a launch_path of /index.html but redirects to / which would exit the app. The two main screens of the app are /#conversations and /#contacts which would also open outside the app.
* SoundCloud (no. 4 most popular app) - Doesn't provide a launch_path, what would we use? (Other popular apps like Twitter, Box and Digg have the same problem.)
* YOUZEEK (no. 7 most popular app) - Provides a launch_path of /helixmini.v4.aspx?source=FirefoxMarketplace but the login page at /Auths/AltDefault.aspx would exit the app
* Evernote - Provides a launch path of /Home.action, the settings panel at /Settings.action would open outside the app

Comment 7

[Ben Francis [:benfrancis]]

One option might be:
* If a "scope" property is provided, use that
* If a "start_url" property is provided (indicating a Web Manifest) but no "scope", use start_url
* If a "launch_path" property is provided (indicating an Open Web App) use "/"
* If none of the above apply, use "/"

This still wouldn't satisfy the W3C proposal that the bookmarked URL be used as a fallback for Web Manifest scope. I think we'd have to change the Apps API to make that information available during installation via mozApps.install()

Comment 8

[Kai-Chih Hu [:khu]]

Johnny, do we plan to implement this one in FxOS 2.2 which will use Gecko 37? Thanks.

Comment 9

[Johnny Stenback (:jst)]

Given the complexity of this feature and its impact on our ecosystem as a whole I don't think we can do this for 2.2. This is a tricky issue and we'll need to scope this work and plan it out well in advance of a release so we can land this early to have time to track down any regressions before this goes out in a release.

Comment 10

[Kai-Chih Hu [:khu]]

Minus this bug due to comment 9.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.