Clarify how manifest image resources are fetched

[marcoscaceres]

Closes #910

This change (choose at least one, delete ones that don't apply):

• Breaks existing normative behavior (please add label "breaking")
• Adds new normative requirements
• Adds new normative recommendations or optional items
• Makes editorial changes (changes informative sections, or changes normative sections without changing behavior)
• Is a "chore" (metadata, formatting, fixing warnings, etc).

Implementation commitment (delete if not making normative changes):

• WebKit (https://bugs.webkit.org)
• Chromium (https://bugs.chromium.org/)
• Gecko (http://bugzilla.mozilla.org)

If change is normative, and it adds or changes a member:

• updated JSON schema

Commit message:

(Fill in. If making normative changes, describe exactly what the behavioral
difference will be.)

Person merging, please make sure that commits are squashed with one of the following as a commit message prefix:

• chore:
• editorial:
• BREAKING CHANGE:
• And use none if it's a normative change

---

Preview | Diff

[dmurph]

My main thoughts here are:

• On Chrome, we download through the document, which can hit things like the service worker, and also shows up in things like the devools network panel
• I hesitate to open up the options here for another user agent to download the icons in a different way, as this reduces consistency here between platforms.
• Normal image fetches from a document get a bunch of things like headers, which might be used by the server to, say, customize the image based on the user's profile, whether they are in an experiment group, etc. Maybe can't fetch unless auth headers are there?

It's hard to know how important keeping this consistent, if there is a requirement out there someone would have here. I think my biggest concern would just be consistency.

HOWEVER - I think also we have an effort to decouple the manifest parsing from the document. There are a lot of benefits there too, allowing services to cache data about a manifest & the icons for distribution. But - yeah - not sure what the right answer is here.

edit: Having this always go through the document also means that you can hit the serviceworker in an offline setting.

[benfrancis]

I tend to agree that icon/image fetching should be possible outside of the document the manifest was linked from. There could be all kinds of architecture designs for how to install an application where the functions of downloading, caching and updating icons are delegated to browser chrome or the underlying operating system. In Firefox OS for example I believe at least at one point icons were initially fetched by browser/system chrome to provide a preview but then stored (in IndexedDB) and managed by the separate homescreen application after installation.

In general anything that helps decouple app installation from the document is a good thing from my point of view.

An edge case I can imagine that could create a problem is if fetching an image resource requires some form of authentication like a cookie being set, but there all kinds of reasons why I think that should be discouraged.

FWIW in WebThings Shell we currently fetch icons from system chrome rather than the document, but there's still work to do there around caching and updating images.

[marcoscaceres]

I got confirmation too that in WebKit it's done through using there document as well (i.e., CSP applies). So yeah, we should just say, go through the algorithm "fetching an image resource".

The problem with decoupling it from the document is that it would break the CSP policies, service worker served icons, etc.

[marcoscaceres]

@benfrancis, although rare, there could be a case where the icons might be pulled from a service worker - which seems like a valid thing to do. In such a case, it would need to through the document context to get to the service worker.

[marcoscaceres]

This needs a request to be passed, a response to be handled.

At written, this doesn't make sense at the moment, because the other spec takes an optional request .... the request needs to come from some context...

We might be able to get away with putting this int the spec with an issue, but it won't buy us much.

This needs to describe, for example, how this interacts with the Cache API via service workers, for instance.

[christianliebel]

The Fetching an image resource algorithm in Image Resource would have to be adjusted.