CODEWITHSUNDEEP
javascriptgeolocationprogressive-web-appsservice-workerlighthouse
McMurphy
McMurphy

Reputation: 1312

Start_url not in ServiceWorker's scope for lighthouse PWA audit "localhost"

EDIT: If I change SW registration to: -

navigator.serviceWorker.register('/Brotkrumen/echo.js')

I get the Install event but ServiceWorker is never READY.

If you run my Brotkrumen PWA from GitHub Pages you'll see from the console log that I get a PWA Install Event and everything is peachy (I'm writing the nice install pop up this w/e). The Lighthouse audit is all green.

The problem is when I run the same code from the local copy of the repository: -

http://localhost:3333/brotkrumen/travelmanager.html

I get this error: -

LightHouse Audit

This is my manifest: -

{
  "short_name": "Brotkrumen",
  "name": "Brotkrumen Web App",
  "description": "Native Background Geolocation POC",
  "icons": [
    {
      "src": "gingerbreadhouse.png",
      "sizes": "48x48 128x128 144x144 192x192 512x512",
      "type": "image/png",
      "purpose": "any"
    },
    {
      "src": "gingerbreadhouse.png",
      "sizes": "48x48 128x128 144x144 192x192 512x512",
      "type": "image/png",
      "purpose": "maskable"
    }
  ],
  "start_url": "/Brotkrumen/TravelManager.html",
  "background_color": "#00ccdd",
  "theme_color": "#00ccdd",
  "display": "fullscreen"
}

The start_url above and my Service Worker registration scope as follows: -

navigator.serviceWorker.register('echo.js', { scope: './' })

These settings were the only combo to work on both the case-sensitive GitHub pages and IIS.

IIS Physical path "C:\repos" with a "Brotkrumen" sub-folder.

In both environments all code and Service Workers function as expected. Except for Windows\Chrome\lighthouse spotting the PWA.

Case sensitive Windows???

Upvotes: 0

Views: 873

Answers (1)

McMurphy
McMurphy

Reputation: 1312

My bad :-( or, at least, My Disbelief!

The only "problem" is the "b" in the browser navigation/URL bar. This works on Windows/IIS: -

http://localhost:3333/Brotkrumen/travelmanager.html

It's as simple as that. And, before you ask, yes it was one of the first things I tried but I didn't realize that Chrome Browser History would see a case-insensitive "exact" match and replace what I typed with the "old" lower-case version. (And, yes, I wasn't paying attention) Once I deleted the "old" url from history and entered the new one, all lighthouse audits were passed.

I enetered a bug with Lighthouse but they disagreed.

For me Windows' and Chrome's case-insensitivity needs to be respected/honoured with a case-INCENSITIVE compare by Lighthouse. Linux/GitHub won't find the sub-folder in the first place, and all other URL case checks (caching etc) are enforced so there is no regression here?

Or Chrome become case sensitive?

Anyway, all's well that ends.

Upvotes: 0

Related Questions