On 8 July 2015 at 04:41, Jonas Sicking <jo...@sicking.cc> wrote: > Given this, and given that I don't actually see a downside to > re-downloading the HTML page again, I definitely think that that's > what we should do. >
Actually the conclusion I drew from the W3C GitHub thread [1] was that we should check for an updated manifest for a pinned site every time the user visits a page of the site (associated with the manifest via a link relation), and download an updated manifest if the cached copy has expired. It's important to do it whilst the site is being used so that the HTTP requests can be sent in the context of the site itself to ensure any necessary cookies, sessions or credentials are set. If the referenced manifest URL has changed, we have to treat the new manifest as belonging to a separate site, because there's no way to ensure that the new manifest refers to the same site as the old manifest. I don't think it's safe to rely on re-downloading the page the site was pinned from in order to try to derive a new manifest URL. A site can be pinned from any page of the site and if the page you pinned the site from is removed then updates will fail. This seems just as likely as the manifest URL changing. It's also not enough to simply do an XHR from the system app to the page URL, the user may need to be logged in in order to fetch the page. I do agree that the W3C manifest spec has a bit of a built-in footgun at the moment which risks unwary web developers using misbehaving CDNs creating manifests which users never get updates for after pinning/installing a site/app, because the default configuration of their CDN is to change the manifest URL when the manifest is updated. I don't think the best solution is to try to work around the spec by inventing our own way of updating which may just break in different ways. I think we need to try to quantify that risk, and if we find it to be significant, propose changes to the spec again. > Also keep in mind that for websites that don't use manifests, but > instead use meta tags, we'll have to re-download the HTML. > It's tricky to determine from the metadata of an arbitrary page of a given site whether a change is representative of the whole site, but yes we're going to have to work around that ambiguity for sites which don't provide a manifest with a clearly defined scope. We can update site metadata when the user visits a page of the site, in the same way that we update page metadata in the places database when the user visits a page. Ben 1. https://github.com/w3c/manifest/issues/384
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
