716739 - Add <iframe app> (or something like that) for installed web apps

Status: RESOLVED DUPLICATE of bug 753978

(Core :: DOM: Core & HTML, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This is a subset of the new APIs needed for <iframe browser>.  Basically, we need
 - <iframe app> is a window.top boundary
 - attempting to navigate away from the "app pages" does something magic, like sending out a VIEW intent.  E.g., clicking a link in an email shouldn't navigate the email app to the link target.

This should be fairly straightforward (though not particularly easy) except for defining what the "app pages" are.  We should have enough information in the manifest to determine that though.  Maybe all app entry points and the set of appcache pages?  Or we could do same-domain-as-app.

Doesn't block demo-phone because we can control what gaia does for the time being.  But we can't control what arbitrary installed apps do.

Comment 1

[Ben Francis [:benfrancis]]

In the Open Web Apps documentation it says "The manifest and app origin (protocol, host name, and port number) are collectively the complete description of an installed app." (https://developer.mozilla.org/en/Apps/Manifest).

This seems to suggest that the scope of an app is defined by a domain and therefore if the user tries to navigate to a link from another domain we should either:
* launch a corresponding app (if an app is installed for that domain)
* open the URL with a browser app via Web Intents (if no app is installed for that domain)

It's worth flagging up that this differs from the way that Chrome Hosted Apps define the scope of an app because their manifests can contain a list of URLs (which can include wildcards) which describe in detail the resources that belong to the app. This allows for apps like http://google.com/calendar as distinct from http://google.com for example and may highlight a limitation of Open Web Apps which could be an obstacle to standardisation.

Please see my manifest comparison here https://wiki.mozilla.org/Apps/ManfiestFormatComparison

Comment 2

[Ben Francis [:benfrancis]]

On a separate note, I'd like to understand a bit more about the difference between <iframe app> and <iframe browser>. You say that the former is a subset of the latter, but I'm not sure about that distinction.

In Gaia's current design the homescreen app doesn't have any controls to navigate an app, but that doesn't have to be the case. As discussed on the b2g mailing list someone might want to implement a homescreen app which distinguishes less between apps and other web pages. Can you definitely say that a homescreen app will never feature a back button for example? Or that the homescreen will never need to access the <title> element of an app, be notified when the title changes or when the page starts and stops loading, refresh the app or stop the app from loading?

I'm not sure that the use cases are as distinct as <iframe app> and <iframe browser> and would suggest that maybe we should either use the same attribute for both (which could also be easier to standardise) or if more granularity is needed then adopt a similar syntax to <iframe sandbox> where by default all features are turned on (or off), but then individual features can be turned off (or on) individually. Something like <iframe browser="allow-navigation allow-content-access allow-content-control"> or <iframe browser="disallow-navigation"> etc.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I'm certainly in favor of unifying more of the interface, but let's work from concrete use cases.  The uses I know of are
 1. "normal" browser "tab".  This is pretty well understood.
 2. "app tab"-style browser "tab".  Like (1), except link chasing works how we discussed for proto-<browser app> (opens new "tab").
 3. "app window" for installed app or page with app manifest.  Has an attached manifest, no external navigation needed for gaia use case, link chasing works like (2), window manager can't reach into internals

In my mind, there are two key distinguishing factors of (3): has a strong identity known to the engine (through manifest), and security issues over an external manager (homescreen) being able to frob its internals.  For example, my SMS app will have the SMS permission bits, but I would never grant that to a window manager/homescreen.  We have a similar issue with (1), but it's like the current setup of fennec on android, where fennec has to ask for permissions for all web APIs it can internally grant access to.  In the case of b2g though, escalated requests can be handled through manifests and app tabs.

Notifying the "tab manager" whenever out-of-domain navigation, which we need for (2)/(3) is attempted is a performance burden on (1), where it's a common case.  The <iframe app> + manifest helps the engine make decisions about whether to put content in its own process or an existing one.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

s/Notifying/Notifying of and waiting for a "redirection" decision/

Comment 5

[Dietrich Ayala (:dietrich)]

Jonas says this is covered by other bugs. He'll note them here.