On 8 July 2015 at 04:36, Jonas Sicking <[email protected]> wrote:

> > But how should we handle the case where the user navigates to a Firefox
> App
> > in the browser (either a legacy hosted Open Web App or a new signed
> > streamable packaged app), and then tries to pin it? Would we a) just pin
> it
> > like a web site using metadata provided by the page and not provide any
> > additional features, keeping the existing separate install flow in the
> > Marketplace or b) require that all Firefox Apps provide a manifest link
> > relation in their pages pointing towards a manifest with proprietary
> Mozilla
> > properties, somehow detect the difference, then internally install the
> app
> > via the exiting Apps API?
> > I would have a strong preference for b), but I'm not sure how feasible
> that
> > is from a BizDev/Evangelism point of view. We'd need to be clear on how
> this
> > is going to work very soon to set those balls rolling.
>
> I don't think it's at all feasible. And it would still cause the user
> to get logged out when you pin the site, which likely means that it's
> worse for the user than simply doing a). I don't think very many
> hosted apps use the extra permissions which means that the difference
> between a) and b) is very little, other than that b) logs you out.
>

Are you you saying that un-signed hosted Firefox Apps should no longer be
able to access alarms, push, audio channels, fmradio or unlimited storage,
or be able to register web activities? So I will no longer be able to
"share" something via Facebook/Twitter/Pinterest for example? Or are you
saying that there should be two separate experiences of these apps/sites
depending on whether you "pin" them from the browser chrome or "install"
them from the Marketplace? Neither of these sound good to me.

For streamable packaged apps in 2.5 we're most likely going to grant
> apps all the needed permissions upon simply navigating to the app. So
> again b) makes very little difference other than logging the user out.
>

Are you saying that signed Firefox Apps will automatically be able to use
alarms, push, audio channels, fmradio, unlimited storage, mozbrowser,
input, mobilenetwork, nfc, systemXHR, tcp-socket, datastore, promptless
fullscreen, system messages and registering web activities simply by
navigating to a URL? Or will we prompt the user for every one of those
features?

> and it's mostly Firefox Apps that
> > Gecko needs to be made aware of.
>
> I'm not sure what you mean by this.


I meant that it seems like for many of the features listed above, pinning a
Firefox App needs to call some API in Gecko to activate those features only
when the app is pinned. But that for pinning a web site/web app with a W3C
manifest we can probably deliver an MVP without needing to call a Gecko API.


> I definitely think that we should
> make use of the apple meta tags to the same extent that we do
> manifests. I believe the fennec team has found that the get a much
> better user experience for their "bookmark to homepage" when making
> use of the apple tags.
>

Yes, we should make use of site/app metadata provided by meta tags,
potentially including proprietary meta tags (with developer warnings) where
necessary for backwards compatibility with a large volume of existing
content.

My view is that for simple site/app metadata (like specifying an
application-name and icon) meta tags in the <head> of an HTML page are
sufficient (though their scope is ambiguous). But to define a more complex
collection of metadata like defining a scope, display mode, default
orientation, start_url, default theme_color, a map of icons and a map of
splash screens, a centralised JSON manifest is more practical.

Incidentally I've come to think about page metadata in the same way. For
simple metadata like type/title/description/image, simple RDFa style meta
tags using the Open Graph vocabularly in <head> are sufficient. For more
complex use cases like complex structured data (e.g. contact details),
associated actions and linked resources, a description in JSON using a
vocabularly like schema.org is more practical.

So for the more complex app features described above, I don't think we can
rely on meta tags in the <head> alone (unless we invent quite a long list
of new meta tags to include in each page for things like registering web
activities). I think we need a page of a site/app to be able to associate
itself with a manifest for use during pinning.

Ben
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to