ServiceWorker cannot be started about wordpress-playground HOT 14 CLOSED

@mho22 Would manually removing the service worker in devtools unblock you? I'm not sure why that problem happens either, perhaps @brandonpayton would have some insights. A quick solution could be to wrap it in try/catch (but only in the local development environment) and propagate the error to the logger.

from wordpress-playground.

@brandonpayton sorry for the delay.

OS : Mac OS Sonoma 14.4.1 (23E224)
Browser : Google chrome Version 123.0.6312.87 (Build officiel) (arm64)
Network issue : index.ts canceled : service-worker.ts?type=module&worker_file:2
Git branch : curl-support

I only have to comment the line 45 in file register-service-worker.ts to make this work :

// Check if there's a new service worker available and, if so, enqueue
// the update:
//await registration.update();

So I suppose if you add a try catch it could maybe solve the issue ?

Edit: I found information on this link stating that the update() method is only available in secure contexts. Currently, I am loading this on localhost via HTTP. Perhaps this could be the explanation. We could consider adding a condition like this:

// Check if there's a new service worker available and, if so, enqueue
// the update:
if( registration.scope.includes( 'https://' ) ) await registration.update();

I am not entirely certain about the reason and solution, by the way.

from wordpress-playground.

I wonder if we can have npm run dev show http://127.0.0.1:5400/website-server/ instead of http://localhost:5400/website-server/ to avoid the possibility of this issue.

I created PR #1209 to use 127.0.0.1 instead.

from wordpress-playground.

@brandonpayton briliant! I suppose we can close this issue.

from wordpress-playground.

Localhost still exists in some places it might be worth updating everything to 127.0.0.1.

In retrospect, it seems obvious that this search should have been done in the original PR. Thank you for bringing this up, @bgrgicak! I made a note to follow up on this.

from wordpress-playground.

@adamziel Anytime the page refreshes, it returns the error. Even if I remove the service worker in devtools manually. I wrapped the line in a try/catch to show you the result :

try
{
	// Check if there's a new service worker available and, if so, enqueue
	// the update:
	await registration.update();
}
catch( error )
{
	console.debug( error );
} 

from wordpress-playground.

Hi @mho22, I don't have any immediate ideas about this, but if you're interested, I am up for joining you for a screen share via WordPress.org Slack (assuming Slack huddles are supported there).

Either way, I have a few questions that might help us troubleshoot and/or reproduce your issue:

• What OS are you using?
• What browser version?
• Do you see any relevant errors in the dev tools network tab?
• Are you running with the latest commits from this repo?

from wordpress-playground.

@mho22, I wonder if this is related to #1196, where Firefox does not support loading a Service Worker script as an ES module.

from wordpress-playground.

It's puzzling how this could just be a problem with updating though.

from wordpress-playground.

While that’s a good find, I’m also confused because I thought Service Workers in general are only allowed in secure contexts: #1098

Could it be that localhost is a special case where one can user service workers but not the update() method? But why would it only fail sometimes?

from wordpress-playground.

Thanks for the info, @mho22.

I just ran into this same issue in Chrome Canary (Version 125.0.6401.0 (Official Build) canary (x86_64)):

Edit: I found information on this link stating that the update() method is only available in secure contexts. Currently, I am loading this on localhost via HTTP. Perhaps this could be the explanation. We could consider adding a condition like this:

Could it be that localhost is a special case where one can user service workers but not the update() method? But why would it only fail sometimes?

@mho22 and @adamziel, localhost is indeed a special according to this:
https://w3c.github.io/webappsec-secure-contexts/#localhost

Section 6.3 of [RFC6761] lays out the resolution of localhost. and names falling within .localhost. as special, and suggests that local resolvers SHOULD/MAY treat them specially. For better or worse, resolvers often ignore these suggestions, and will send localhost to the network for resolution in a number of circumstances.

Given that uncertainty, user agents MAY treat localhost names as having potentially trustworthy origins if and only if they also adhere to the localhost name resolution rules spelled out in [let-localhost-be-localhost] (which boil down to ensuring that localhost never resolves to a non-loopback address).

This made me wonder about explicitly using the loopback address 127.0.0.1 instead of "localhost", and that did the trick. Chrome loaded local Playground successfully and presumably was able to update the service worker as part of the process.

I wonder if we can have npm run dev show http://127.0.0.1:5400/website-server/ instead of http://localhost:5400/website-server/ to avoid the possibility of this issue.

from wordpress-playground.

I'am having the same problem in Firefox asking for both http://localhost:5400 and http://127.0.0.1:5400

Firefox version is 115.9.1esr (64 bit)
built on Gentoo

errors are:

TypeError: ServiceWorker script at http://localhost:5400/service-worker.ts?type=module&worker_file for scope http://localhost:5400/ threw an exception during script evaluation. remote.html:69:12
    <anonima> remote.html:69

Uncaught (in promise) TypeError: ServiceWorker script at http://localhost:5400/service-worker.ts?type=module&worker_file for scope http://localhost:5400/ threw an exception during script evaluation. comlink.ts:259:8
Firefox non può stabilire una connessione con il server ws://localhost:5400/. client.ts:77:17

There is no issue in chrome 123.0.6312.105 (on the same linux machine).
In chrome playground works querying both http://localhost:5400 and http://127.0.0.1:5400

from wordpress-playground.

Localhost still exists in some places it might be worth updating everything to 127.0.0.1.

@MocioF we also had this issue in Firefox before changing to 127.0.0.1.

from wordpress-playground.

@MocioF, I believe this is due to Firefox not yet supporting ES module-based service workers. See #330.

On playground.wordpress.net, the built service worker script does not contain any syntax specific to ES modules, so it works in Firefox. But during local dev with npm run dev, the service worker contains import statements that require ES module support, which Firefox does not yet provide for service workers.

from wordpress-playground.