702157 - implement webapps manifest discovery

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Andreas Gal :gal]

Implement WebApps manifest discovery using a link.

With the DOM API pages can use programmatic JS to trigger discovery, but a link is easier to analyze statically and will help search engines index web apps.

Comment 1

[Andreas Gal :gal]

Fabrice, do you want to work on this next after bug 697383?

Comment 2

[[:fabrice] Fabrice Desré]

(In reply to Andreas Gal :gal from comment #1)
> Fabrice, do you want to work on this next after bug 697383?

sure, assigning to myself.

Comment 3

[Andreas Gal :gal]

++fabrice

Comment 4

[[:fabrice] Fabrice Desré]

Note that there is no platform work needed here, since we already fire DOMLinkAdded events for all <link> elements.

What we need to do is:
- decide on a value for the "rel" attribute.
- write some glue between this event handler and the App repository backend.

Comment 5

[Shane Caraveo (:mixedpuppy)]

The jetpack addon used to use a link rel=application-manifest to discover manifests and provide an offer to install.  This has been removed in favor of installation via the app store.  You might want to touch base with Mike Hanson about why it was decided to remove that.

Comment 6

[Andreas Gal :gal]

meeting fabrice/mhanson/brendan/gal:

- propose in the same webapps proposal
- only allow same origin for now

Comment 7

[Michael Hanson]

The Jetpack offer feature was backed out because the UX was annoying, not because of any particular problem with the LINK definition - and I have no strong feelings on the right 'rel' attribute.

We did prototype a discover-and-buy feature, which used a web activity to communicate with the app marketplace to get a price and execute a buy, which was interesting, but beyond the scope of this bug.

My one feedback based on prototyping experience is that it is difficult for a desktop browser to make an offer-to-install that is better than what the site can offer itself.  Faaborg suggested that when you bookmark a site with a manifest we offer to install the app instead.  On mobile, the "install" flow, from primary menu UX, is cleaner and clearer, and avoids much of the confusion.

Comment 8

[Andreas Gal :gal]

The annoyance factor can be mitigated with a one-time door-hanger as long there is a secondary way to get to the install dialog. The UI/UX guys should figure this out.

Comment 9

[Shane Caraveo (:mixedpuppy)]

IMO it is better for the site to advertise via an install button than being annoyed with my UA by repeated install dialogs/panels.

However, we've talked about this a bit, I think there are a couple good idea's for methods of dealing with when to offer an install (considering this from a firefox perspective).  

1. if there is a saved password in the login manager, offer an install
2. if frequency is over some threshold, offer an install

If I say don't ask again, the link info could still be collected for an awesome bar style search for apps or perhaps to weight searches in the market by sites you've visited, but really, don't ask me again.

Comment 10

[[:fabrice] Fabrice Desré]

Attachment: wip patch

Add support for <link rel="application-manifest" href="app.manifest" title="FooBar"> by adding a (initially closed) doorhanger.

Comment 11

[[:fabrice] Fabrice Desré]

Attachment: screenshot

Comment 12

[[:fabrice] Fabrice Desré]

Attachment: wip patch

updated patch, actually working...

Comment 13

[[:fabrice] Fabrice Desré]

Attachment: patch

Rebased patch (applies on top of bug 697006)

Comment 14

[[:fabrice] Fabrice Desré]

Attachment: wip patch

Comment 15

[Alex Limi (:limi) — Firefox UX Team]

Comment on attachment 577994 [details] [diff] [review]
wip patch

(In reply to Shane Caraveo (:mixedpuppy) from comment #9)
> IMO it is better for the site to advertise via an install button than being
> annoyed with my UA by repeated install dialogs/panels.

I agree with this. Doorhangers are never automatically triggered, but are a result of the user performing an action (and not as part of general navigation).

> 1. if there is a saved password in the login manager, offer an install
> 2. if frequency is over some threshold, offer an install
> 
> If I say don't ask again, the link info could still be collected for an
> awesome bar style search for apps or perhaps to weight searches in the
> market by sites you've visited, but really, don't ask me again.

These are reasonable ideas, but I think we should keep it simple, and stick to models that have already been proven to work.

Here's what I would suggest:

1. User navigates to web site
2. Site can have a <link rel /> autodiscovery mechanism for robot consumption, but this doesn't trigger any UI, it just makes it possible to know that a page has a web app or more associated with it.
3. The web site has the responsibility of providing a button or link that lets you install their web app. Sites generally like to show that they have more value to offer (as an app would be), and that they are "with it" and have things like apps. (similar things from the past have been RSS, add-ons, etc). It also gives web apps more visibility across many sites, just like Twitter and Facebook buttons have become ubiquitous. 
4. Once the user click the link/button to install the web app, it works in the same way as installing an add-on: doorhanger pops down, asks the user if they want to install the web app.

I can't tell if this is what the patch already does, but if it is, ui-review+ from me. If not, let's make it work that way. :)

Let me know if there is something I'm not aware of here that I didn't cover, or other constraints/issues that this wouldn't solve.

Comment 16

[[:fabrice] Fabrice Desré]

If we really want this "do nothing" behavior, then we don't need this patch at all.

The UI for when a user clicks on an "Install" button from a page is implemented in bug 697006 (with a tab modal dialog, not a doorhanger)

Comment 17

[Andreas Gal :gal]

I had a chat with limi. He really thinks the browser shouldn't show a door hanger when coming across a site with a manifest link/rel. Instead, we will remember that we saw that manifest and we can populate a recommendation from it on the about:home tab ("Hey, the following sites you visited frequently have webapps, want to install them?"). Server-side search can do the same. So lets drop the UI piece for now, and just add support for the link/rel, and optionally a way to track the manifests (has to go into places I am afraid, so maybe we do that later?).

Comment 18

[Mounir Lamouri (:mounir)]

(In reply to Andreas Gal :gal from comment #17)
> I had a chat with limi. He really thinks the browser shouldn't show a door
> hanger when coming across a site with a manifest link/rel. Instead, we will
> remember that we saw that manifest and we can populate a recommendation from
> it on the about:home tab ("Hey, the following sites you visited frequently
> have webapps, want to install them?").

What if the user doesn't use about:home but another home page?

Comment 19

[Andreas Gal :gal]

I think Limi said most users don't change away from about:home. Don't shoot the messenger here, I am just executing what the UI team likes :) We need a first iteration in place, we can improve from there. We also have about:apps as a stop-gap measure.

Comment 20

[Mounir Lamouri (:mounir)]

I'm not shooting the messenger, I'm asking him :)
But in general, I wonder if we have stats about about:home usage. Otherwise, I tend to think exactly the opposite: for what I see around me, users that were using Firefox before about:home tend to have a home page different from the default one. Anyway, I guess we will be able to handle that in a follow-up.

Comment 21

[Andreas Gal :gal]

I think the mid-term goal is to split "new tab" from "about:home" and put this stuff onto the new tab start page (the way chrome does). But again, I am just getting popcorn here and leaning back and seeing what UI/UX comes up with, and then I will go and build that :)

Comment 22

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

Don't want to step outside my front yard, but what about a URL bar indicator for "discovered" apps?  (Possibly in addition to new-tab/home suggestion UI.)

Comment 23

[[:fabrice] Fabrice Desré]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #22)
> Don't want to step outside my front yard, but what about a URL bar indicator
> for "discovered" apps?  (Possibly in addition to new-tab/home suggestion UI.)

This is what the current patch did, and was rejected.

Comment 24

[Andreas Gal :gal]

Limi argued that people don't check the URL bar when they go to a site because thats not what they are focused on. They are focused on the site.

Comment 25

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

Sorry, ignore me.

Comment 26

[[:fabrice] Fabrice Desré]

Attachment: updated patch

New patch, in which we store the discovered manifests in their own json file.

I'm not using places annotations for two reasons:
- we can have several links per page leading to storing arrays of link data, and I'm not sure annotations are appropriate for such data structures.
- fennec is not using places and there's no reason we should not have support for it.

Comment 27

[Robert Kaiser]

Could we have something like a menu entry or optional toolbar button (like RSS/feeds) or such that can give those interested a direct indication and possibility to install? Just an idea, not sure it it's feasible. We unfortunately don't have a common indicator of "this site offers stuff we can act on, like search plugins, feeds, apps, etc." but also no idea it that's a good idea.
I guess with the concepts I've seen of future designs where we had apps available from some kind of dropdown, IIRC, we could easily add it there.

Comment 28

[Dietrich Ayala (:dietrich)]

Not a blocker for V1. Nice to have. Will re-review after V1.

Comment 29

[Sylvestre Ledru [:Sylvestre]]

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