Crashing at loading step 4/4 in new browser releases (e.g. FF 122.0) with: Failed to load worker script 0x80530013

[that-ben]

Hi, we're using a build from last year on MR and it was working fine until today under Firefox 121.0.1 and also on many previous releases. I just tried it 2 minutes ago on FireFox 121.0.1 and it was loading just fine, but after applying the 122.0 update and restarting, InfiniteMac does not load anymore and hangs at loading step 4/4. I've confirmed with other users as well. Also, it does the same under Safari on macOS 14.2.1 and also on iOS Safari on a modern iPhone. It's working fine under FF 121.0.1 but not under FF 122.0.

Was there a bug fix over the last 8 months that prevented the crash at step 4/4 with this kind of JS error in the console?

NetworkError: WorkerGlobalScope.importScripts: Failed to load worker script at blob:https://emulate-sheepshaverjs.macintoshrepository.org/cb037672-127c-48a7-a840-efece5e2607a (nsresult = 0x80530013)

In the error above, if I copy/paste the URL blob:https://emulate-sheepshaverjs.macintoshrepository.org/cb037672-127c-48a7-a840-efece5e2607a in my browser, it displays the whole JS file just fine.

[mihaip]

I stopped using importScripts with https://github.com/mihaip/infinite-mac/commit/b221259595d323d2c45cd2175fdc7ce9287c3097, so I'm guessing you'll want to pick up a build that has that.

[that-ben]

I see, thanks for pointing that out... and was that decision to stop using importScripts based on a possible incompatibility with more modern browsers?

I'm also asking because I'm wondering if the new code you made that replaces importScripts will still work in older Firefox versions that ran under W7 (I don't have a W7 PC right now to test with as I upgraded my W7 PC to W10 on December 31st, because Steam stopped working on W7 on that day). If it doesn't, I will keep both IM builds with a comment next to them. This would be useful that we have at least one build for very old computers running W7. Mozilla stopped releasing Firefox builds for W7 like 4 months ago and those last builds I remember were working perfectly fine with importScripts enabled builds of IM... and as a matter of fact, regardless of the OS, it worked all the way to and including FF 121.0.1 but not 122.0

I lol'ed at your source in index.js "__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED" 🤣

OK, so in the hope of replacing the deprecated IM build mentioned above, I grabbed the current build, installed it on my host and tested with Mac OS 9.0 and everything works as expected, the emulator boots up, it seems to be usable on my host, with one exception and I don't know what would cause that as I've never had that with the previous InfiniteMac build, do you know what could cause that? The emulator works despite this error, so I'm confused as to what it means. I'm serving everything with HTTPS and I even tried to force every single request through .htaccess as HTTPS, but it didn't make a difference.

[mihaip]

I see, thanks for pointing that out... and was that decision to stop using importScripts based on a possible incompatibility with more modern browsers?

It was a general modernization of the build system, not aimed at fixing issues. The switch away from importScripts was a downstream effect, the commit message has the full yak shave history.

I'm also asking because I'm wondering if the new code you made that replaces importScripts will still work in older Firefox versions that ran under W7

When I implemented it in late May 2023 I tested with the current versions of Safari, Firefox and Chrome. Based on https://wiki.mozilla.org/index.php?title=Release_Management/Calendar&redirect=no that would have been Firefox 112 or 113.

I lol'ed at your source in index.js "__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED" 🤣

It comes from React, I can't take credit for it.

I'm serving everything with HTTPS and I even tried to force every single request through .htaccess as HTTPS, but it didn't make a difference.

Not familiar with this error, but https://stackoverflow.com/questions/49539306 has some possible causes (wrong MIME type, third-party cookies being blocked, etc.)

[that-ben]

Thanks to an user on MR who posted their screenshot of their Chrome console, I got a refined error and it became clear that the file RunDefMac-878e86b8.js had a bad definition of the worker scope. Firefox really dropped the ball on this as it offered (as you could see yesterday) absolutely no detail whatsoever to the "insecure" problem. Anyway, in your file it was: {scope:"/",type:a} ...but it should really be: {scope:"/assets/",type:a} Did you force this scope through another file perhaps for this to work on InfiniteMac? Because the error goes away and the worker installs and activates when I set the scope to "/assets/" instead of "/" so perhaps in a .htaccess you forge a header to mimic that?

[mihaip]

It's intentional that I use / as the worker scope. There's a corresponding header on the server side (https://github.com/mihaip/infinite-mac/blob/de7553f1a61297c52bb5003dc1623da169ee3c9e/workers-site/index.ts#L87-L90) that enables it.

[that-ben]

Oh yeah! I totally overlooked that new header! Thanks for pointing that out! 👍 Works perfectly fine when adding that header to the .htaccess file and even after reverting the RunDefMac-878e86b8.js file too. PERFECT! Thanks Mihai! Will be sending yet another donation for you next week.

[mihaip]

Glad it worked!

[that-ben]

Donation sent! THANKS for what you're doing with InfiniteMac!