982800 - Browser API: Add a mozbrowsermanifestchange event to detect <link rel="manifest"> elements

Status: RESOLVED FIXED

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

Description

[Ben Francis [:benfrancis]]

The W3C Manifest specification [1] requires the use of a manifest referenced by a link element, e.g.

<link rel="manifest" href="add_to_homescreen.json">

In order to implement this specification in Gaia for Firefox OS, I suggest adding a new event to tell the system browser/window manager when such a link element is present, so that it can retrieve and process the manifest.

This is similar to bug 962626 which added a metachange event which can be used as a fallback for when a manifest is not referenced.

1. http://w3c.github.io/manifest/#using-a-link-element-to-link-to-a-manifest

Comment 1

[Ben Francis [:benfrancis]]

On second thoughts, given that we already have an iconchange event for <link rel="icon">, maybe we should just have a manifestchange event for <link rel="manifest">?

That or combine the two into linkchange.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Note, we have internally chrome only DOMLinkAdded/Removed.
http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLLinkElement.cpp#149
but do we need here some change event whenever the value of certain attribute changes?

Comment 3

[[:fabrice] Fabrice Desré]

(In reply to Olli Pettay [:smaug] from comment #2)
> Note, we have internally chrome only DOMLinkAdded/Removed.
> http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/
> HTMLLinkElement.cpp#149
> but do we need here some change event whenever the value of certain
> attribute changes?

I don't think we need that. And yes, we'll use DOMLinkAdded like we already do at https://mxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementChildPreload.js#182

Comment 4

[(no longer active)]

(In reply to comment #1)
> On second thoughts, given that we already have an iconchange event for <link
> rel="icon">, maybe we should just have a manifestchange event for <link
> rel="manifest">?
> 
> That or combine the two into linkchange.

Is there any difference between how the specs for the two say we need to implement things?

Comment 5

[Andrea Marchesini [:baku]]

Attachment: manifest.patch

I took this bug because it was similar to the meta change event patch I wrote a while ago.

Comment 6

[(no longer active)]

So rel="manifest" is not spec'ed yet as far as I can tell.  Marcos, do you plan to get Hixie spec it here? <http://www.whatwg.org/specs/web-apps/current-work/#linkTypes>

Comment 7

[Andrea Marchesini [:baku]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/68b0f7e79ceb

Comment 8

[Marcos Caceres [:marcosc]]

@ehsan, the spec for "manifest" is here: http://w3c.github.io/manifest/#linking

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/68b0f7e79ceb

Comment 10

[(no longer active)]

(In reply to comment #8)
> @ehsan, the spec for "manifest" is here: http://w3c.github.io/manifest/#linking

Thanks.  Reading that, we'll have similar incompatibilities with the spec with regards to multiple <link rel=manifest> elements. :/

Comment 11

[Ben Francis [:benfrancis]]

Nice turnaround guys, thanks!

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #10)
> Reading that, we'll have similar incompatibilities with the spec
> with regards to multiple <link rel=manifest> elements. :/

Incompatibilities with what?

The manifest spec says "In cases where more than one link element with a manifest link type appears in a document, the user agent MUST use the first inserted link element and ignore all subsequent link elements with a manifest link type (even if the first element was erroneous)."

So can we can just listen for the first event in Gaia and ignore any subsequent events for the same document?

Or do you mean incompatible in a different way?

Comment 12

[(no longer active)]

(In reply to comment #11)
> Nice turnaround guys, thanks!
> 
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #10)
> > Reading that, we'll have similar incompatibilities with the spec
> > with regards to multiple <link rel=manifest> elements. :/
> 
> Incompatibilities with what?
> 
> The manifest spec says "In cases where more than one link element with a
> manifest link type appears in a document, the user agent MUST use the first
> inserted link element and ignore all subsequent link elements with a manifest
> link type (even if the first element was erroneous)."
> 
> So can we can just listen for the first event in Gaia and ignore any subsequent
> events for the same document?

If we consume the notification that way, we would be compliant with this spec.  But if we do the dumb/default thing that is, registering a listener and just handle the notification in the listener without worrying about if we have seen that exact notification before, then we would be violating the spec.

> Or do you mean incompatible in a different way?

For other link/meta tags, the spec calls us to do even crazier things such as picking the first link element with that @rel value in the document order, etc.  FWIW we have already agreed that the case of multiple link/meta elements is an edge case and that it's fine to not follow the spec.  :-)