implement webapps manifest discovery

RESOLVED WONTFIX

Status

defect
RESOLVED WONTFIX
8 years ago
6 months ago

People

(Reporter: gal, Assigned: fabrice)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 5 obsolete attachments)

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
Fabrice, do you want to work on this next after bug 697383?
(Assignee)

Comment 2

8 years ago
(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.
Assignee: nobody → fabrice
(Reporter)

Comment 3

8 years ago
++fabrice
(Assignee)

Comment 4

8 years ago
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.
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.
(Reporter)

Updated

8 years ago
Blocks: 702367
(Reporter)

Comment 6

8 years ago
meeting fabrice/mhanson/brendan/gal:

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

Comment 7

8 years ago
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.
(Reporter)

Comment 8

8 years ago
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.
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.
(Assignee)

Comment 10

8 years ago
Posted patch wip patch (obsolete) — Splinter Review
Add support for <link rel="application-manifest" href="app.manifest" title="FooBar"> by adding a (initially closed) doorhanger.
(Assignee)

Comment 11

8 years ago
Posted image screenshot (obsolete) —
(Assignee)

Comment 12

8 years ago
Posted patch wip patch (obsolete) — Splinter Review
updated patch, actually working...
Attachment #575043 - Attachment is obsolete: true
(Assignee)

Comment 13

8 years ago
Posted patch patch (obsolete) — Splinter Review
Rebased patch (applies on top of bug 697006)
Attachment #575050 - Attachment is obsolete: true
(Assignee)

Comment 14

8 years ago
Posted patch wip patch (obsolete) — Splinter Review
Attachment #577994 - Flags: ui-review?(limi)
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.
Attachment #577994 - Flags: ui-review?(limi) → ui-review+
(Assignee)

Comment 16

8 years ago
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)
(Reporter)

Comment 17

8 years ago
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?).
(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?
(Reporter)

Comment 19

8 years ago
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.
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.
(Reporter)

Comment 21

8 years ago
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 :)
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.)
(Assignee)

Comment 23

8 years ago
(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.
(Reporter)

Comment 24

8 years ago
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.
(Assignee)

Comment 26

8 years ago
Posted patch updated patchSplinter Review
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.
Attachment #575044 - Attachment is obsolete: true
Attachment #576538 - Attachment is obsolete: true
Attachment #577994 - Attachment is obsolete: true

Comment 27

8 years ago
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.
Assignee: fabrice → nobody
Component: DOM → DOM: Mozilla Extensions
Assignee: nobody → fabrice
Not a blocker for V1. Nice to have. Will re-review after V1.
No longer blocks: b2g-product-phone
Whiteboard: [b2g:blocking-]
blocking-basecamp: --- → -
Whiteboard: [b2g:blocking-]
Component: DOM: Mozilla Extensions → DOM: Apps

Updated

2 years ago
Product: Core → Core Graveyard
Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.
Status: NEW → RESOLVED
blocking-basecamp: - → ---
Last Resolved: 6 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.