1699047 - NS_ERROR_INTERCEPTION_FAILED errors are rendered poorly

Status: NEW

(Core :: DOM: Service Workers, defect, P3)

Description

[Martin Thomson [:mt:]]

STR:

Load https://kagami.github.io/avif.js/
Now load https://kagami.github.io/avif.js/Mexico.5f45d60c.avif
Refresh

Expected:

An image is shown.

Actual:

Oops.

The site at https://kagami.github.io/avif.js/Mexico.5f45d60c.avif has experienced a network protocol violation that cannot be repaired.

NS_ERROR_INTERCEPTION_FAILED shows in the network panel of the devtools.

Analysis:

This site uses a service worker to polyfill AVIF support (which is native in Nightly, but it probably doesn't know or care about that). For some reason, this service worker fails on reload.

While this is probably a bug in the implementation of the service worker, the problem is that the error page doesn't attribute blame to the service worker. Instead, it looks like a networking error (it's not; unregistering the service worker fixes the problem, but I have image.avif.enabled set to true).

Improving this error page might help keep it clear what is going on. Maybe there should be a button on that page to unregister the service worker.

There might be a webcompat bug here as well, but I'll let the avif.js maintainers work that out.

Comment 1

[thepra]

I'm having the same issue, in my case I've images behind api calls such as this with CSP whitelisted in the domain of use of this resource like this:

content-security-policy: 
    default-src 'self'; 
    script-src 'report-sample' 'self' 'unsafe-eval' 'unsafe-inline' https://js.stripe.com/v3/; 
    style-src 'report-sample' 'self' 'unsafe-inline'; 
    object-src 'none'; 
    base-uri 'self'; 
    connect-src 'self' https://plausible.collanon.app https://js.stripe.com; 
    font-src 'self'; 
    frame-src 'self'; 
    img-src 'self' data: https://contents.nuvola.xyz; 
    manifest-src 'self'; 
    media-src 'self'; 
    worker-src 'self'; 
    upgrade-insecure-requests;

I'm also working with service worker through Blazor WebAssembly in my case.
From the Firefox 93.0 (64-bit) console I have this error message:

Failed to load ‘https://contents.nuvola.xyz/api/assets/ca33fd3c-d1a4-4c8e-b9ad-daae97c3e60d’. A ServiceWorker passed a promise to FetchEvent.respondWith() that rejected with ‘TypeError: NetworkError when attempting to fetch resource.’

The issue is that sometimes it does work well and sometimes it's not, here's the request/response headers when it works well:
REQUEST

GET /api/assets/220586e3-603f-479e-a62c-b6c1b8b80478 HTTP/2
Host: contents.nuvola.xyz
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: image/avif,image/webp,*/*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
Pragma: no-cache
Cache-Control: no-cache

RESPONSE

HTTP/2 200 OK
server: nginx
date: Fri, 15 Oct 2021 08:50:11 GMT
content-type: image/png
content-length: 57476
accept-ranges: bytes
etag: W/1
content-disposition: inline; filename=logoCollAnonQuickPlusGold.png; filename*=UTF-8''logoCollAnonQuickPlusGold.png
strict-transport-security: max-age=15768000; includeSubDomains; preload;
x-robots-tag: none
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
referrer-policy: no-referrer
x-frame-options: SAMEORIGIN
X-Firefox-Spdy: h2

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

That was mitigated by bug 1503072 adding the dom.serviceWorkers.mitigations.bypass_on_fault pref which is on by default. In the event of interception navigation fetch failures (not subresource fetches) we will reload the page bypassing the ServiceWorker. If I turn that pref off, we do see the page, but the expectation is the pref is always on.

The page, if shown, is misleading.

edit: I removed incorrect script line numbers, see comment 3.

That said, although we don't expect the error page to be shown, we probably do need to keep it around as a backstop, in which case we probably should try and customize the string reported since it is very misleading.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

That's not the line, it's this in https://kagami.github.io/home/kagami/code/avif.js/avif-sw.js, starting line 138.

self.addEventListener("fetch", e => {
  // TODO(Kagami): Better check for AVIF. HTTP headers?
  if (e.request.url.match(/\.avif$/i)) {
    const id = taskCounter++;
    setClientWaiting(e.clientId);
    e.respondWith(new Promise((resolve, reject) => {
      taskById[id] = {resolve, reject, toBlob: true};
      clients.get(e.clientId).then(client =>
        // TODO(Kagami): Apply request headers?
        fetch(e.request.url, {credentials: "same-origin"})
          .then(res => res.arrayBuffer())
          .then(avifArr => decodeAvif(client, id, avifArr))
      ).catch(reject);
    }).then(blob => {
      delete taskById[id];
      // TODO(Kagami): Apply response metadata?
      return new Response(blob);
    }, err => {
      delete taskById[id];
      throw err;
    }));
  }
});

e.clientId is somehow an empty string, thus clients.get(e.clientId) returns undefined, and decodeAvif is called with undefined for the first argument, which then throws with TypeError, ultimately causing the FetchEvent fail.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

Thanks for the clarification; apologies for still having been confused about where the error was given your attempts to make it clear in the zoom call!

The good news is that error makes more sense, that's probably bug 1938529 which may be bug 1487534. We can keep this bug about the error page, though.