Closed Bug 1003890 Opened 10 years ago Closed 6 years ago

[Meta] W3C Manifest implementation in FxOS

Categories

(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::System::Browser Chrome
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: benfrancis, Unassigned)

References

(Depends on 1 open bug)

Details

This bug tracks an early implementation of the W3C Manifest draft specification http://w3c.github.io/manifest in Gaia.
Depends on: webmanifest
Depends on: 1038833
Depends on: 1071581
Depends on: 1071583
Depends on: 1001861
Depends on: 1075704
Thanks for the feedback in bug 1003876 Fabrice and Jonas, I suggest moving the discussion into this bug as it applies to web manifests more broadly.

So we've identified that there's an issue with fetching web manifests, icons and OpenSearch description documents using the URLs provided to Gaia via the existing Browser API because in some edge cases a specific browser context may be required when fetching those resources. It seems like extending XMLHttpRequest or a new method on the Browser API could provide a solution to that problem.

Gecko is going to need to know how to parse web manifests, at least for implementations in other Firefox browsers, and probably as part of the Apps API if that API is to support the installation of apps using the web manifest format.

Gaia is going to need to know how to parse web manifests in order to determine whether to add a bookmark or install an app when bookmarking to homescreen, and to extract metadata from the manifest in the case of bookmarking.

It would be preferable to only have to fetch a manifest once, so it might be useful for window.navigator.mozApps.install() to accept a parsed manifest object as an optional argument (bug 1075704) so that it doesn't have to fetch the manifest again if Gaia already has it.

This leaves open the question of whether Gaia should fetch the manifest using a special XMLHttpRequest, the manifest data should be provided in the payload of the mozbrowsermanifestchange event, or we should add a specific getManifest method to the Browser API. I don't have strong feelings about that, but it might be useful to receive a manifestchange event in order to inform the user a web page is claiming to have an available app to install, without always needing to download the manifest data in case it isn't subsequently used.

With all of this in mind I would suggest that we:
* Continue to move forward with code in Gaia which fetches a manifest file using the URL provided in a manifestchange event, when the user chooses to bookmark an app to the homescreen.
* Adapt Marcos' manifest parser as a WebManifestHelper in Gaia which knows how to parse a web manifest
* Extend XMLHttpRequest to allow the fetching of resources with a specific browser context
* Extend the Apps API to support the web manifest format (making use of Marcos' parser) and accept a parsed manifest object as an optional parameter

What do you think?
Flags: needinfo?(mcaceres)
Flags: needinfo?(jonas)
Flags: needinfo?(fabrice)
Note that if the "browser" display mode didn't exist, this could potentially all be much simpler.

We could just always internally call window.navigator.mozApps.install() with the manifest URL when the user chooses to "add app to homescreen" on a page which specifies a manifest in a link relation.

That wouldn't require any new XMLHttpRequest features, wouldn't require mozApps.install() to take an object as an argument and wouldn't require fetching or parsing of manifests in Gaia. We'd just add support for the web manifest format to the existing Apps API.

I am kind of wondering what benefit there is to providing a web manifest with the "browser" display mode over plain old bookmarking...
Ben, what's the problem with the "browser" display mode? It's unclear to me how it would be different from "standalone" - at least on b2g.
Flags: needinfo?(fabrice)
Sorry, I didn't explain that very well.

The spec says that the "browser" display mode:
> "Opens the web application using the platform-specific convention for opening hyperlinks in the user agent (e.g., in a browser tab or a new window) [0]."

The way that I have interpreted this for Firefox OS is that the browser display mode is basically just a BrowserWindow[1]. A browser window doesn't respect application scope, can be navigated to any URL and uses a data jar shared with all other browser windows. The other three display modes are more like stand alone apps so would be added to the app registry and therefore open in an app window, respect application scope and get their own data jar.

The only reason Gaia really needs to download and parse the manifest at the bookmarking/installation stage is to figure out whether to add a bookmark (which would open in a browser window) or install an app (which would open in an app window). If the browser display mode didn't exist then it could just hand everything off to the Apps API because everything would be an app.

Other alternatives I can think of are that the Apps API detects the browser display mode and fires an add to homescreen web activity rather than proceeding, or all manifests are installed as an app but apps with a browser display mode are opened in browser windows instead of app windows and somehow all share the same data jar.

Or is there another interpretation of the spec?

0. http://w3c.github.io/manifest/#display-modes
1. https://bugzilla.mozilla.org/show_bug.cgi?id=934631
(In reply to Ben Francis [:benfrancis] from comment #4)
> The way that I have interpreted this for Firefox OS is that the browser
> display mode is basically just a BrowserWindow[1].

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1003883#c1
There is nothing in the spec that really speaks about the security contexts in any detail - i.e., there is no mention of what to do with cookies, etc... So, at the moment, adding a web application to the homescreen should share cookies with the browser. The display mode is not bound to any security rules: each document has its own default display mode (until we introduce a URL scope). That is what causes pages to go from one display mode to another as the user navigates a web application.  
 
So - default display mode is browser: 
1. user goes to foo.com/index.html 
2. install foo.com/manifest.json (default display mode will be standalone)
3. open foo.com/index.html from homescreen? now display mode is "standalone" as the default for this document. 
4. user goes to foo.com/bar.html - display mode now "browser". 
5. user presses back button - display mode now again "standalone". 

Hope that makes sense.
Flags: needinfo?(mcaceres)
(In reply to Marcos Caceres [:marcosc] from comment #6)
> There is nothing in the spec that really speaks about the security contexts
> in any detail - i.e., there is no mention of what to do with cookies, etc...
> So, at the moment, adding a web application to the homescreen should share
> cookies with the browser. 

It's true the spec doesn't say anything about cookies, but perhaps this is an implementation detail which could be left down to the individual user agent. Installed web apps in Firefox OS currently have their own data jar, I think Chrome also has the concept of data "partitions".

> The display mode is not bound to any security
> rules: each document has its own default display mode (until we introduce a
> URL scope). That is what causes pages to go from one display mode to another
> as the user navigates a web application.

I think this just shows how the Web Manifest spec doesn't really make much sense without a "scope" property to define the URL scope to which the manifest applies.
  
> So - default display mode is browser: 
> 1. user goes to foo.com/index.html 
> 2. install foo.com/manifest.json (default display mode will be standalone)
> 3. open foo.com/index.html from homescreen? now display mode is "standalone"
> as the default for this document. 
> 4. user goes to foo.com/bar.html - display mode now "browser". 
> 5. user presses back button - display mode now again "standalone".

Switching display modes on every page navigation sounds nauseating. I'm not even sure how this would work in practice as the user agent doesn't know that the page it has just navigated to has a different display mode until it has downloaded and parsed the manifest for the page. It could end up switching from standalone to browser and back to standalone again during a page load. I'm pretty sure this isn't how the implementation in Chrome 39 works [1].

I hope this user experience can also be left as an implementation detail for the user agent.

> Hope that makes sense.

It does make sense, thank you. It's also slightly insane :)

In my interpretations of the spec described above I'm kind of assuming that app scope exists, or at least that when an web app installed from a web manifest is launched inside an app window, that window is fixed in the specified display mode.

1. https://developer.chrome.com/multidevice/android/installtohomescreen
OK, unless anyone has any serious objections I'm going to proceed with what I described in comment 1. I'm going to try adding an experimental "Add app to homescreen" entry in the Firefox OS browser overflow menu for web pages which specify a web manifest.

Selecting that menu item will fetch the manifest. If the display mode is set to "browser" it will add a bookmark to the bookmarks datastore using whatever metadata is provided in the manifest (though probably ignoring "orientation" as the Chrome implementation does). If the display mode is set to fullscreen, standalone or minimal-ui then it will call mozApps.install() with the URL of the web manifest (for the time being, until we decide whether it should accept a manifest object as an alternative argument). I have submitted a proposed patch in bug 1075716 to add support for the Web Manifest MIME type to the Apps API.

Remaining support for the Web Manifest format in the Apps API can be tracked by bug 1075704.
(In reply to Ben Francis [:benfrancis] from comment #7)
> (In reply to Marcos Caceres [:marcosc] from comment #6)
> > There is nothing in the spec that really speaks about the security contexts
> > in any detail - i.e., there is no mention of what to do with cookies, etc...
> > So, at the moment, adding a web application to the homescreen should share
> > cookies with the browser. 
> 
> It's true the spec doesn't say anything about cookies, but perhaps this is
> an implementation detail which could be left down to the individual user
> agent. Installed web apps in Firefox OS currently have their own data jar, I
> think Chrome also has the concept of data "partitions".

No, there "add to homescreen" works exactly as I described: it just open in a browser tab.
 
> > The display mode is not bound to any security
> > rules: each document has its own default display mode (until we introduce a
> > URL scope). That is what causes pages to go from one display mode to another
> > as the user navigates a web application.
> 
> I think this just shows how the Web Manifest spec doesn't really make much
> sense without a "scope" property to define the URL scope to which the
> manifest applies.

Proponents of single page apps would disagree with you there - specially given that iOS has been supporting this exact behavior for about 4 years now. However, I'm no fan of single page apps (and have shown that single page apps on iOS don't work in practice [2]). 

So yes, multi-page apps are going to have a bad time. However, this is fine for now. We will get scope - but it's going to require baby steps. 
   
> > So - default display mode is browser: 
> > 1. user goes to foo.com/index.html 
> > 2. install foo.com/manifest.json (default display mode will be standalone)
> > 3. open foo.com/index.html from homescreen? now display mode is "standalone"
> > as the default for this document. 
> > 4. user goes to foo.com/bar.html - display mode now "browser". 
> > 5. user presses back button - display mode now again "standalone".
> 
> Switching display modes on every page navigation sounds nauseating.

Yep, it is. It's really annoying on iOS too ^_^. However, this is a feature, not a bug.

Consider, when you switch from a game (landscape) to the phone dialer (portrait). It's the same here. 

> I'm not
> even sure how this would work in practice as the user agent doesn't know
> that the page it has just navigated to has a different display mode until it
> has downloaded and parsed the manifest for the page.

It doesn't need to, because it always defaults to browser. The only case where this would be noticeable would be if you navigate to an application that has been already installed: and there is would make total sense to change layout. 

For example, I navigate from Twitter (portrait locked) to play an online multi-player game I previously installed by following a link from twitter (someone DM's to play).  

> It could end up
> switching from standalone to browser and back to standalone again during a
> page load. I'm pretty sure this isn't how the implementation in Chrome 39
> works [1].

Implementation in Chrome locks you into a default display mode and orientation, even across origins. This is bad, IMO. The only saving grace is that an address bar is always present. I'm sure that will be fixed over time. 

Having said that, we need to have alignment across browser engines so it's important to make sure we talk to the Chrome team. I'll point Mounir to this discussion.  

> I hope this user experience can also be left as an implementation detail for
> the user agent.

I think parts of it should, and that's what the spec says: particularly, what each of the display modes mean is left to the implementation. I think it's exciting, because we can play around a bit with what "browser" mode means.  
 
> > Hope that makes sense.
> 
> It does make sense, thank you. It's also slightly insane :)

LOL! :D

> In my interpretations of the spec described above I'm kind of assuming that
> app scope exists, or at least that when an web app installed from a web
> manifest is launched inside an app window, that window is fixed in the
> specified display mode.

I think your experience with FxOS, and my lack of experience with FxOS, is causing us to reach different conclusions. I don't see "apps" as in any way special - they are just plain old web pages. I just see the manifest as a way of *hinting* orientation and what browser chrome should/should not be there for a web page. 

Yes, at some point the hinting will apply to a "scope" of URL space, but this will need to work for apps that don't even bother defining a scope - which is a totally fine and valid thing to do in a manifest. So we need to deal with the current situation regardless of scope.  
 
> 1. https://developer.chrome.com/multidevice/android/installtohomescreen


[2] https://github.com/w3c-webmob/installable-webapps/blob/gh-pages/ios_standalone/README.md
(In reply to Ben Francis [:benfrancis] from comment #8)
> OK, unless anyone has any serious objections I'm going to proceed with what
> I described in comment 1. I'm going to try adding an experimental "Add app
> to homescreen" entry in the Firefox OS browser overflow menu for web pages
> which specify a web manifest.
> 
> Selecting that menu item will fetch the manifest. If the display mode is set
> to "browser" it will add a bookmark to the bookmarks datastore using
> whatever metadata is provided in the manifest (though probably ignoring
> "orientation" as the Chrome implementation does).

The Chrome implementation doesn't ignore orientation? What do you mean? 

> If the display mode is set
> to fullscreen, standalone or minimal-ui then it will call mozApps.install()
> with the URL of the web manifest (for the time being, until we decide
> whether it should accept a manifest object as an alternative argument). I
> have submitted a proposed patch in bug 1075716 to add support for the Web
> Manifest MIME type to the Apps API.

I still hold that trashing cookies is bad. But I think this is a good start none the less! 

> Remaining support for the Web Manifest format in the Apps API can be tracked
> by bug 1075704.

Ok, looking forward to see where this gets to. I'm going to try to submit the manifest obtainer/fetcher today for review too. Hopefully we can start converging in the next few weeks!
After talking to a few more people about this in the office here in Toronto, a sensible solution might be to clone domain cookies and allow access to domain specific passwords for the bookmarked site. That would address my concerns about having to re-login again to a site I was just at (e.g., facebook), while also providing history and process separation between apps added to the homescreen and the browser. 

This would also address user's expectations that adding to homescreen actually "installed" the application - this is not my personal expectation, but asking a few (somewhat unrepresentative) people it seems that people do expect that. Seperation after adding to homescreen would then avoid tainting browsing history, etc. while also allowing apps to be displayed in modes independent of browser. 

Applications would still behave the same way as I described, allowing people to jump into either the web browser or into an installed application seamlessly - that is, if the URL is one in scope of those that are installed, then the user has the choice to use the installed app or continue in the browser (I still think this is problematic, but I'm sure it can be dealt with easily because of how few applications users actually install). This would then would allow users to then log out of installed applications in either the browser or in the application without trashing the cookies of the other, which would be nice.
(In reply to Marcos Caceres [:marcosc] from comment #9)
> (In reply to Ben Francis [:benfrancis] from comment #7)
> > I'm not
> > even sure how this would work in practice as the user agent doesn't know
> > that the page it has just navigated to has a different display mode until it
> > has downloaded and parsed the manifest for the page.
> 
> It doesn't need to, because it always defaults to browser. The only case
> where this would be noticeable would be if you navigate to an application
> that has been already installed: and there is would make total sense to
> change layout. 

I was thinking of the use case of navigating between pages within the same app which all specify the standalone display mode. It seems iOS doesn't support this (!), but Chrome 39 does and it just keeps you in the same display mode. I'm proposing that as long as you remain within the scope of the app (by default the origin of the manifest) the display mode should stay the same.

> > It could end up
> > switching from standalone to browser and back to standalone again during a
> > page load. I'm pretty sure this isn't how the implementation in Chrome 39
> > works [1].
> 
> Implementation in Chrome locks you into a default display mode and
> orientation, even across origins. This is bad, IMO. The only saving grace is
> that an address bar is always present. I'm sure that will be fixed over
> time.

I think the bar showing the current domain only appears if you navigate outside of the origin of the web app. See "Navigating to external pages from a web app" in the documentation. I think with App Scope we've agreed that doing this in a web app on Firefox OS would take you out of the app window, into a browser window or another app window.

> > In my interpretations of the spec described above I'm kind of assuming that
> > app scope exists, or at least that when an web app installed from a web
> > manifest is launched inside an app window, that window is fixed in the
> > specified display mode.
> 
> I think your experience with FxOS, and my lack of experience with FxOS, is
> causing us to reach different conclusions. 

Perhaps, yes, I've never owned an iOS device. However, I don't think my conclusions are particularly tied to Firefox OS either because there are things about our current apps implementation I think we could better. I've been closely following web apps on Android, Chrome OS, Fire OS and Ubuntu Unity as well, among others.

> I don't see "apps" as in any way
> special - they are just plain old web pages. I just see the manifest as a
> way of *hinting* orientation and what browser chrome should/should not be
> there for a web page.

The conclusion that I have reached is that web app content should work equally well inside and outside of the browser, but that the process of "installing" a standalone web app is like slicing off a piece of the web to use separately from the browser [1].

> Yes, at some point the hinting will apply to a "scope" of URL space, but
> this will need to work for apps that don't even bother defining a scope -
> which is a totally fine and valid thing to do in a manifest. So we need to
> deal with the current situation regardless of scope.

In my view the default scope of a web app should be anything which comes from the same origin as the manifest. The scope property just gives you more granularity by letting you slice a single origin into multiple web apps or into app and non-app content.

> The Chrome implementation doesn't ignore orientation? What do you mean? 

It currently supports orientation for the standalone display mode (and fullscreen which falls back to standalone), but ignores orientation for the browser display mode (and the minimal-ui display mode which falls back to browser) [2].

> I still hold that trashing cookies is bad. But I think this is a good start none the less!

I don't have a strong opinion on this. Fabrice and Jonas suggested that installing from a manifest with certain display modes should install an app into the app registry in Firefox OS. Apps on Firefox OS get their own data jar.

> my
> concerns about having to re-login again to a site I was just at (e.g.,
> facebook)

I agree that's annoying.

> clone domain cookies and allow access to
> domain specific passwords for the bookmarked site.

I don't have an opinion on that, but Jonas might.

> while also providing history and process separation between apps
> added to the homescreen and the browser.

I don't mind whether history is separated, but I would like Rocketbar to eventually be able to index history results from both the browser and installed apps. Once we have App Scope you should be able to jump directly to a news article you previously visited inside a news app from your Rocketbar results for example.

> Applications would still behave the same way as I described, allowing people
> to jump into either the web browser or into an installed application
> seamlessly - that is, if the URL is one in scope of those that are
> installed, then the user has the choice to use the installed app or continue
> in the browser (I still think this is problematic, but I'm sure it can be
> dealt with easily because of how few applications users actually install).

I personally feel that if a URL is within the scope of an app, it should just load in the app. The user chose to split that part of the web off separate from the browser when installing it. This may be more Firefox OS specific though where there's less of a distinction between apps and the browser, other user agents may want to offer a choice.

> This would then would allow users to then log out of installed applications
> in either the browser or in the application without trashing the cookies of
> the other, which would be nice.

Or potentially confusing. If I log out of Facebook I want to log out of Facebook.

> I'm going to try to submit the manifest obtainer/fetcher today for review too.
> Hopefully we can start converging in the next few weeks!

Sounds good!

> [2]
> https://github.com/w3c-webmob/installable-webapps/blob/gh-pages/
> ios_standalone/README.md

"iOS standalone apps don't support following hyperlinks" says it all really! It isn't really the web without hypertext, let's put the H back in HTML5 ;)

1. http://tola.me.uk/blog/2014/10/03/what-is-a-web-app/
2. https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/android/shortcut_helper.cc&l=262
(In reply to Ben Francis [:benfrancis] from comment #12)
> (In reply to Marcos Caceres [:marcosc] from comment #9)
> I was thinking of the use case of navigating between pages within the same
> app which all specify the standalone display mode. It seems iOS doesn't
> support this (!),

Not "out of the box", and it's standard practice to hack around it. 

> but Chrome 39 does and it just keeps you in the same
> display mode. I'm proposing that as long as you remain within the scope of
> the app (by default the origin of the manifest) the display mode should stay
> the same.

I'm proposing the same thing ^_^

> I think the bar showing the current domain only appears if you navigate
> outside of the origin of the web app. See "Navigating to external pages from
> a web app" in the documentation. I think with App Scope we've agreed that
> doing this in a web app on Firefox OS would take you out of the app window,
> into a browser window or another app window.

Yep, exactly. 
 
> > I think your experience with FxOS, and my lack of experience with FxOS, is
> > causing us to reach different conclusions. 
> 
> Perhaps, yes, I've never owned an iOS device.

You should get one if you can. Remember that the standard is trying to cater for then needs of all platforms.  

> However, I don't think my
> conclusions are particularly tied to Firefox OS either because there are
> things about our current apps implementation I think we could better. I've
> been closely following web apps on Android, Chrome OS, Fire OS and Ubuntu
> Unity as well, among others.

Ok, good to hear you are looking at those too. 

> > I don't see "apps" as in any way
> > special - they are just plain old web pages. I just see the manifest as a
> > way of *hinting* orientation and what browser chrome should/should not be
> > there for a web page.
> 
> The conclusion that I have reached is that web app content should work
> equally well inside and outside of the browser, but that the process of
> "installing" a standalone web app is like slicing off a piece of the web to
> use separately from the browser [1].

I'm not quite there yet. Over the last 7 years of me doing this, I've seen a lot of platforms fail at trying to get clever at trying to pull web apps out of the browser and fail miserably in the process. Hence my insistence of baby steps.
 
> In my view the default scope of a web app should be anything which comes
> from the same origin as the manifest. The scope property just gives you more
> granularity by letting you slice a single origin into multiple web apps or
> into app and non-app content.
> 
> > The Chrome implementation doesn't ignore orientation? What do you mean? 
> 
> It currently supports orientation for the standalone display mode (and
> fullscreen which falls back to standalone), but ignores orientation for the
> browser display mode (and the minimal-ui display mode which falls back to
> browser) [2].

Ah, that's as expected per spec (you can't lock orientation in some display modes, as it wouldn't make sense - and a UA is not expected to support every display mode; only browser). I thought you meant that one couldn't set the default orientation to, say, landscape.

> > I still hold that trashing cookies is bad. But I think this is a good start none the less!
> 
> I don't have a strong opinion on this. Fabrice and Jonas suggested that
> installing from a manifest with certain display modes should install an app
> into the app registry in Firefox OS. Apps on Firefox OS get their own data
> jar.
> 
> > my
> > concerns about having to re-login again to a site I was just at (e.g.,
> > facebook)
> 
> I agree that's annoying.
> 
> > clone domain cookies and allow access to
> > domain specific passwords for the bookmarked site.
> 
> I don't have an opinion on that, but Jonas might.

Ok, we might need to set up a call next week or something. However, I want more people in the discussion that have a stake in the evolution of the Web Platform to have a say about how this should work. We don't get many shots at doing this, so need to make sure we do it right. 

> > while also providing history and process separation between apps
> > added to the homescreen and the browser.
> 
> I don't mind whether history is separated, but I would like Rocketbar to
> eventually be able to index history results from both the browser and
> installed apps. Once we have App Scope you should be able to jump directly
> to a news article you previously visited inside a news app from your
> Rocketbar results for example.

Yep, that would be good. Though apps might need to be run in private browsing mode then. 
 
> I personally feel that if a URL is within the scope of an app, it should
> just load in the app. The user chose to split that part of the web off
> separate from the browser when installing it. This may be more Firefox OS
> specific though where there's less of a distinction between apps and the
> browser, other user agents may want to offer a choice.

I think we need to play with this by prototyping - as you are doing. We can also see the effects by looking at what Chrome has done. I'm meeting with Mounir at W3C TPAC to discuss this also - but might also run a larger session during TPAC to further discuss how we turn web pages into something app like. 

> > This would then would allow users to then log out of installed applications
> > in either the browser or in the application without trashing the cookies of
> > the other, which would be nice.
> 
> Or potentially confusing. If I log out of Facebook I want to log out of
> Facebook.

On iOS, I bounce between the browser apps and the native apps quite a bit. Sometimes I log in/out of the Web ones. 

> > I'm going to try to submit the manifest obtainer/fetcher today for review too.
> > Hopefully we can start converging in the next few weeks!

Hit some mochitest-browser snags :( Aiming for Monday now.
No longer depends on: 1001861
> With all of this in mind I would suggest that we:
> * Continue to move forward with code in Gaia which fetches a manifest file
> using the URL provided in a manifestchange event, when the user chooses to
> bookmark an app to the homescreen.
> * Adapt Marcos' manifest parser as a WebManifestHelper in Gaia which knows
> how to parse a web manifest
> * Extend XMLHttpRequest to allow the fetching of resources with a specific
> browser context
> * Extend the Apps API to support the web manifest format (making use of
> Marcos' parser) and accept a parsed manifest object as an optional parameter

So if I understand correctly, when the user navigates to a page that has a manifest we'll fire a manifestchange event.

When the user then selects "bookmark to homepage", we'll use something like XHR({ context: iframeelement }) to fetch the manifest as well as an appropriate icon from the manifest.

We'll then display UI to the user indicating the icon and app name that we'll use for the bookmark. (Do we allow the user to modify that name?).

Once the user press 'ok', we use some new function in the Apps API to create a new app using the manifest. We'll also have to pass the URI of the manifest so that the Apps API can download updated manifests as needed.

Does this sound right? If so then it sounds great.


We should also talk about if we should enable bookmarking "the app" vs. "the current page". I.e. it might be good to enable the user to bookmark a deep-link into an app. Though there's lots of edge cases to cover here so might be worth discussion in a better forum than bugzilla.
Flags: needinfo?(jonas)
(In reply to Jonas Sicking (:sicking) from comment #14)
> So if I understand correctly, when the user navigates to a page that has a
> manifest we'll fire a manifestchange event.

I still think the manifestchange event might be problematic. Someone needs to confirm, does the event fire if a link element: 

* is removed from the document?
* the manifest token is removed from the rel attribute?
* is prepended or otherwise moved in tree order above/below another link element whose rel is manifest?

The risk is that the event is giving you either stale or incorrect information. The only way to assure you are getting the actual manifest is to sync-check the Document for a matching manifest in the way the spec says (i.e., just get the link element when you need it). Hence, right now, the event serves very little purpose. This is why I propose only getting the manifest when needed (and improving that with heuristics, when there is a high probability that the user will likely want to add to homescreen).  

This is not to say the event is totally useless: the event MAY only comes into play after a manifest has been "applied" to a document - in case a service worker is needed or the scope has to change (things that are not yet supported in the Web Manifest at this point and are still subject to change). Hence, IMO, given the above, the event is absolutely not a good mechanism to rely on at install time. It may also not be a good mechanism to rely on even after install, because it will lead to some unpredictable behavior. 

> When the user then selects "bookmark to homepage", we'll use something like
> XHR({ context: iframeelement }) to fetch the manifest as well as an
> appropriate icon from the manifest.
> 
> We'll then display UI to the user indicating the icon and app name that
> we'll use for the bookmark. (Do we allow the user to modify that name?).

I would expect so. 

> Once the user press 'ok', we use some new function in the Apps API to create
> a new app using the manifest. We'll also have to pass the URI of the
> manifest so that the Apps API can download updated manifests as needed.
> 
> Does this sound right? If so then it sounds great.
> 
> 
> We should also talk about if we should enable bookmarking "the app" vs. "the
> current page".

I think we should. 

>  I.e. it might be good to enable the user to bookmark a
> deep-link into an app. Though there's lots of edge cases to cover here so
> might be worth discussion in a better forum than bugzilla.

Agree.
Depends on: 1086666
Depends on: 1086669
(In reply to Jonas Sicking (:sicking) from comment #14)
> > With all of this in mind I would suggest that we:
> > * Continue to move forward with code in Gaia which fetches a manifest file
> > using the URL provided in a manifestchange event, when the user chooses to
> > bookmark an app to the homescreen.
> > * Adapt Marcos' manifest parser as a WebManifestHelper in Gaia which knows
> > how to parse a web manifest
> > * Extend XMLHttpRequest to allow the fetching of resources with a specific
> > browser context
> > * Extend the Apps API to support the web manifest format (making use of
> > Marcos' parser) and accept a parsed manifest object as an optional parameter
> 
> So if I understand correctly, when the user navigates to a page that has a
> manifest we'll fire a manifestchange event.
> 
> When the user then selects "bookmark to homepage", we'll use something like
> XHR({ context: iframeelement }) to fetch the manifest as well as an
> appropriate icon from the manifest.
> 
> We'll then display UI to the user indicating the icon and app name that
> we'll use for the bookmark. 

Exactly. I've just filed bug 1086666 for the new XHR feature, although I doubt it will be ready in time for my intial patch in bug 1003876. (I suspect mozApps.install() also has the restriction of not being able to install apps using an HTTP authenticated manifest file.)

> (Do we allow the user to modify that name?).

I think that's up to UX. Currently the user can modify the name of a bookmark, but not an app.

> Once the user press 'ok', we use some new function in the Apps API to create
> a new app using the manifest. We'll also have to pass the URI of the
> manifest so that the Apps API can download updated manifests as needed.
> 
> Does this sound right? If so then it sounds great.

Exactly. I have filed bug 1086669 for the Apps API feature. My initial patch in bug 1003876 will just pass the manifest URL so the manifest will be downloaded twice.

> We should also talk about if we should enable bookmarking "the app" vs. "the
> current page". I.e. it might be good to enable the user to bookmark a
> deep-link into an app. Though there's lots of edge cases to cover here so
> might be worth discussion in a better forum than bugzilla.

I think we should. In my initial patch I am adding an "Add app to home screen" option alongside an "Add page to homescreen" option, the former only appears when a manifest URL has been detected. "Add page" will use the document icon and page title, whereas "Add app" will use the app name and icon from the manifest.

I will bring this up with UX and perhaps suggest using the terms "Bookmark Page" and "Install App" to further differentiate the two.
(In reply to Marcos Caceres [:marcosc] from comment #15)
> I still think the manifestchange event might be problematic. Someone needs
> to confirm, does the event fire if a link element: 
> 
> * is removed from the document?
> * the manifest token is removed from the rel attribute?
> * is prepended or otherwise moved in tree order above/below another link
> element whose rel is manifest?

Let's look into this, although if there are problems I imagine the same issues apply to mozbrowsericonchange and mozbrowseropensearch.

> The risk is that the event is giving you either stale or incorrect
> information. The only way to assure you are getting the actual manifest is
> to sync-check the Document for a matching manifest in the way the spec says
> (i.e., just get the link element when you need it). Hence, right now, the
> event serves very little purpose. This is why I propose only getting the
> manifest when needed (and improving that with heuristics, when there is a
> high probability that the user will likely want to add to homescreen).

To flip this around, depending on the UX design this may require Gaia to try to get a manifest on every locationchange event because it won't know whether or not a manifest link relation is defined and therefore whether to offer the "install app" option to the user. The current approach is more consistent with the rest of the Browser API so if there is an issue then again I would suggest it is more wide reaching.

I think the kind of heuristics you're describing are going to be tricky to implement in Firefox OS. Gecko may not have access to the browsing history to determine visit frequency for example. I would suggest simple consistent behaviour rather than trying to do something clever, but again I think this down to UX.

> This is not to say the event is totally useless: the event MAY only comes
> into play after a manifest has been "applied" to a document - in case a
> service worker is needed or the scope has to change (things that are not yet
> supported in the Web Manifest at this point and are still subject to
> change). Hence, IMO, given the above, the event is absolutely not a good
> mechanism to rely on at install time. It may also not be a good mechanism to
> rely on even after install, because it will lead to some unpredictable
> behavior.

The way I imagine this is that the scope and service_worker properties would only get parsed during installation, and installation could only occur after a manifestchange event has fired to inform Gaia that a manifest exists. If another manifestchange event fires with a different URL after installation it will have no effect unless the app is re-installed. If these manifest properties are to be applied on initial page load rather than during installation, I think there are many other issues to figure out such as those described at https://github.com/w3c/manifest/issues/233

I think if you seriously want to explore the idea of Web Manifest as a progressive enhancement to a web page navigated to in a browser as opposed to metadata for app installation then those issues need to be fleshed out a lot more.
Ben, given that we won't fetch the manifest until the user presses the 'star' icon either way, it seems fine to me to go look in the DOM for <link rel=manifest> only once the user press the 'star' icon. Firing the manifestchange event to keep an up-to-date manifest URL in the parent process doesn't seem to bring any significant benefits, and definitely has downsides in terms of complexity and CPU usage.

That said, I don't think this is a blocking issue. Though it would be good to fix before we ship so that we properly support DOM-modified <link rel=manifest>.

I think the simplest solution would be to add a getMetaData("link"/"meta", "manifest") to the browser API.
(In reply to Jonas Sicking (:sicking) from comment #18)
> Ben, given that we won't fetch the manifest until the user presses the
> 'star' icon either way, it seems fine to me to go look in the DOM for <link
> rel=manifest> only once the user press the 'star' icon. Firing the
> manifestchange event to keep an up-to-date manifest URL in the parent
> process doesn't seem to bring any significant benefits, and definitely has
> downsides in terms of complexity and CPU usage.
> That said, I don't think this is a blocking issue. Though it would be good
> to fix before we ship so that we properly support DOM-modified <link
> rel=manifest>.
> I think the simplest solution would be to add a getMetaData("link"/"meta",
> "manifest") to the browser API.

Yep, that makes sense too.

Like I said, it depends on the UI design. One possibility is that we notify the user that the current web page is part of a web app they can install by way of a door hanger or something similar (bug 1003889) when they navigate to it. That example would require polling every web page for a manifest link relation if there wasn't a manifestchange event.

We don't have a star icon in 2.1+, just an overflow menu which does many things. So we'd at least have to call getMetaData() every time the overflow menu is displayed if we wanted a separate UI element for "install app" vs. "bookmark page".

I'm not particularly attached to any solution, just want to highlight that certain API designs make certain UI designs easier to implement and we shouldn't make too many assumptions at this stage :)
Ah, makes sense. Yeah, we should figure out what UX we want and then decide what internal API we want based on that.
Note that the manifest can be used in other context, not just for installing. For example, one can build a speed-dial preview window from the metadata. It could also be used when constructing a view of recently visited websites. In other words, please don't assume that the only role this metadata has is in some installation process or that having a manifest necessarily translates into an "installable" web app.
We will use the manifest to negotiate language fallback chain for the app (manifest stores the "available languages" portion)
(In reply to Zibi Braniecki [:gandalf] from comment #22)
> We will use the manifest to negotiate language fallback chain for the app
> (manifest stores the "available languages" portion)

Please note that this feature doesn't yet exist in the W3C manifest format. We are looking to add something like that soon. 

See: https://github.com/w3c/manifest/issues/211
(In reply to Marcos Caceres [:marcosc] from comment #21)
> Note that the manifest can be used in other context, not just for
> installing.

Sure. But let's build one feature at a time.
Depends on: 1088009
Depends on: 1091786
Summary: [Meta] W3C Manifest implementation → [Meta] W3C Manifest implementation in FxOS
No longer depends on: 1091786
Depends on: 1134657
Depends on: 1134795
Depends on: 1148442
Hi Ben, you mentioned elsewhere that you already had support for W3C Manifest in FxOS. Is this bug a dup? Can it be closed?
Flags: needinfo?(bfrancis)
It isn't that simple I'm afraid.

As of B2G 2.6 we have an implementation of Web Manifest mainly in the Gaia layer which supports:
* Fetching manifests, but using system XHR rather than a spec-compliant approach (so it doesn't respect CSP or work for HTTP authenticated manifests for example)
* icons for pinned sites
* start_url to launch pinned sites
* theme_color for pinned sites
* scope for deep linking into pinned sites
* name/short_name for homescreen launchers

Icons, names and theme_color are actually supported on page load too, not just once a site has been pinned to the homescreen.

Features intentionally not supported, not yet supported or no longer supported include:
* lang property
* dir property
* description property
* display property
* orientation property
* background_color property
* related_applications property
* Installability criteria (app install prompts)
* install event
* Updates (although this was removed from the spec)
* display-mode CSS feature
* CSP

The B2G Transition Project [1] is entering its last couple of weeks and once the transition branches have been merged back into master/m-c, W3C web apps will be the *only* types of apps supported by B2G (mozApps is being removed), so I expect support to further improve over time.

1. https://wiki.mozilla.org/B2G/Transition_Project
Flags: needinfo?(bfrancis)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.