Bug 311872
| Summary: | `_loadAndDecodeImage:` does not conform to the "fetching an image resource" algorithm | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Marcos Caceres <marcosc> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | beidson, webkit-bug-importer |
| Priority: | P2 | ||
| Version: | WebKit Local Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Marcos Caceres
The Image Resource spec (https://w3c.github.io/image-resource/#fetching-an-image-resource) defines a "fetching an image resource" algorithm that requires the fetch request's Client be set to the context object's relevant settings object:
If |request| is `undefined`:
1. Set |request| to a new Request.
2. Set request/URL to image's src.
3. Set request/Destination to "image".
4. Set request/Client to the context object's relevant settings object.
Note: Client is required here so the appropriate CSP can be applied.
The Web App Manifest spec (https://github.com/w3c/manifest/pull/1171) adds a normative requirement that user agents MUST fetch manifest image resources using this algorithm.
WebKit's current implementation of `_loadAndDecodeImage:` routes the request directly to the network process via `NetworkConnectionToWebProcess::loadImageForDecoding` → `NetworkSessionCocoa::loadImageForDecoding`, constructing a bare `NetworkLoadParameters` with only the URL set. This bypasses the document's client context, meaning:
1. CSP `img-src` directives are not applied to manifest image fetches.
2. Service workers registered for the manifest's scope cannot intercept the fetch.
The fix should route manifest image resource fetches through the page's resource loading infrastructure so that the relevant settings object is used as the fetch client, consistent with what Chrome (`DownloadImageInFrame`) and Firefox (`window.fetch()` in content) already do.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |