Closed Bug 982800 Opened 6 years ago Closed 6 years ago

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

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: benfrancis, Assigned: baku)

Details

Attachments

(1 file)

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
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.
Summary: Browser API: Add a mozbrowserlinkchange event to detect <link> elements → Browser API: Add a mozbrowsermanifestchange event to detect <link rel="manifest"> elements
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?
Summary: Browser API: Add a mozbrowsermanifestchange event to detect <link rel="manifest"> elements → Browser API: Add a mozbrowserlinkchange event to detect <link> elements
Summary: Browser API: Add a mozbrowserlinkchange event to detect <link> elements → Browser API: Add a mozbrowsermanifestchange event to detect <link rel="manifest"> elements
(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
(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?
Assignee: nobody → amarchesini
Attached patch manifest.patchSplinter Review
I took this bug because it was similar to the meta change event patch I wrote a while ago.
Attachment #8390429 - Flags: review?(ehsan)
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>
Flags: needinfo?(mcaceres)
Attachment #8390429 - Flags: review?(ehsan) → review+
@ehsan, the spec for "manifest" is here: http://w3c.github.io/manifest/#linking
Flags: needinfo?(mcaceres)
https://hg.mozilla.org/mozilla-central/rev/68b0f7e79ceb
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
(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. :/
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?
(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.  :-)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.