works-offline: false positive for photopea.com

[brendankenny]

Provide the steps to reproduce

1. Run LH on https://www.photopea.com/

What is the current result?

works offline

What is the expected result?

does not work offline.

This can be seen if you go offline manually and load the page, or just look at the SW (nothing is cached).

Lighthouse instead reports that the page does work offline. The check is working correctly from Lighthouse's perspective (or at least from the offline gatherer's perspective). You can see that the page loads, and if you look at the network record it's inspecting:

Main Network Record

{
  "requestId": "8267C81B408AEA0D7BC17077050D81BF",
  "connectionId": "0",
  "connectionReused": false,
  "url": "https://www.photopea.com/",
  "protocol": "http/1.1",
  "isSecure": true,
  "isValid": true,
  "parsedURL": {
    "scheme": "https",
    "host": "www.photopea.com",
    "securityOrigin": "https://www.photopea.com"
  },
  "documentURL": "https://www.photopea.com/",
  "startTime": 1384312.160637,
  "endTime": 1384312.333087,
  "responseReceivedTime": 1384312.3328230001,
  "transferSize": 0,
  "resourceSize": 7250,
  "fromDiskCache": false,
  "fromMemoryCache": false,
  "finished": true,
  "requestMethod": "GET",
  "statusCode": 200,
  "failed": false,
  "localizedFailDescription": "",
  "initiator": {
    "type": "other"
  },
  "timing": {
    "requestTime": 1384312.160637,
    "proxyStart": -1,
    "proxyEnd": -1,
    "dnsStart": -1,
    "dnsEnd": -1,
    "connectStart": -1,
    "connectEnd": -1,
    "sslStart": -1,
    "sslEnd": -1,
    "workerStart": -1,
    "workerReady": -1,
    "sendStart": 1.579,
    "sendEnd": 1.579,
    "pushStart": 0,
    "pushEnd": 0,
    "receiveHeadersEnd": 172.186
  },
  "resourceType": "Document",
  "mimeType": "text/html",
  "priority": "VeryHigh",
  "responseHeaders": [
    {
      "name": "Accept-Ranges",
      "value": "bytes"
    },
    {
      "name": "Cache-Control",
      "value": "max-age=60"
    },
    {
      "name": "Content-Encoding",
      "value": "gzip"
    },
    {
      "name": "Content-Length",
      "value": "2908"
    },
    {
      "name": "Content-Type",
      "value": "text/html; charset=utf-8"
    },
    {
      "name": "Date",
      "value": "Wed, 07 Nov 2018 19:26:10 GMT"
    },
    {
      "name": "ETag",
      "value": "\"38193c-1c52-579d7e52da39a\""
    },
    {
      "name": "Expires",
      "value": "Wed, 07 Nov 2018 19:27:10 GMT"
    },
    {
      "name": "Last-Modified",
      "value": "Sun, 04 Nov 2018 14:50:53 GMT"
    },
    {
      "name": "Server",
      "value": "Apache"
    },
    {
      "name": "Vary",
      "value": "Accept-Encoding,User-Agent"
    }
  ],
  "responseHeadersText": "",
  "fetchedViaServiceWorker": true,
  "frameId": "D9A2A740C7E7226949F579341841EEB9",
  "isLinkPreload": false
}

The url matches, statusCode is 200, and fetchedViaServiceWorker is true (and fromDiskCache and fromMemoryCache are false, to boot).

However, adding a breakpoint there and connecting to the chrome being tested, there's still nothing in the cache and the sw is throwing errors.

So where is that record coming from?

[jeffposnick]

Taking a guess, but Cache-Control: max-age=60 on their HTML document might be relevant? The https://www.photopea.com/sw.js fetch handler looks like:

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request)
      .then(function(response) {
        // Cache hit - return response
        if (response) {
          return response;
        }
        return fetch(event.request);
      }
    )
  );
});

I could imagine fetch(event.request) getting fulfilled from the HTTP cache thanks their Cache-Control usage, and the fact that the fulfillment happens inside the service worker's fetch handler might explain why fromDiskCache/fromMemoryCache are false.

[brendankenny]

Ah, that seems very probable. We should see what we can do to be able to detect that.

Then there's the audit-level question of "if it works offline, does it matter?" :) Right now we define that narrowly as navigating to about:blank, going offline, and navigating back, but that might not be sufficient.

[tomayac]

Hmm 🤔. So there's no cache storage cache at all, so the response variable in the sw code can definitely never be truthy:

Which means, we always go through the "else" case of fetch(event.request). Could it be that somehow it sets the --disable-storage-reset flag? I tested in the extension and the DevTools Audits variant, and both said it loads offline.

[cdegit]

I'm running into the same issue. I created a small project to help reproduce the issue, if that's useful at all. 😄

[photopea]

Guys, I am really scared by Google now. Many people just want to add the icon to their homescreen, which will open a specific website without a browser UI.

Google decided, that it should be allowed only to websites with a service worker. So I have to add the "empty" service worker to my website, just to allow people to add that icon. I think it is really wrong, as the empty service worker does not do anything, and it is just an extra HTTP request. I am afraid, that when 99% of the web experience will be done in Chromium, nobody will have power to argue with Google about the web standards, as Google will be free to define what the standard is.

[brendankenny]

Confirmed this case is now properly detected in LH 7.0 after the changes to PWA installability detection.

Thanks so much for the super-easy-to-use repro case, @cdegit!