Web page error after modifying the sample program

[xjpch]

I'm not very familiar with compiling to web pages.

I can run the sample program normally, but as long as I modify the title or any string in app.rs, the browser will report the following error, and it will go blank and cannot display anything. I guarantee that the modified content is correct, because everything runs normally on this machine. But it doesn't work properly on the web page. I can even open the wasm link directly and it is normal.

I have tried before
http://127.0.0.1:8080
http://127.0.0.1:8080/index.html
http://127.0.0.1:8080/index.html#dev
The results are all the same.

error message
Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.

The resource http://127.0.0.1:8080/eframe_template-a5ff6bdc28275b99_bg.wasm was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate as value and it is preloaded intentionally.

[amPerl]

dev tools -> application -> clear site data should fix this. not sure what exactly goes wrong in the service worker, haven't been able to reproduce

[kelvie]

I've been able to get around this by commenting out the fetch eventListener code in sw.js, haven't had time to debug why (I'm on firefox/linux).

[chrisdsloan]

I had the same problem as OP and have a bit more information.

I had the same error message. To make sure it wasn't something I had done, I cloned eframe_template and built it as is. The first error message was complaining about eframe_template_.js. The second was complaining about the .wasm file.

What I learned is that when I did a hard reload, it would all work. When I made a change and trunk rebuilt and told the app to reload, it pulled up an index.html which had a different hash in the file name. I think that originally that file did exist, but when I cleaned everything up (trunk clean) and removed the dist directories, it was gone and was not regenerated. In fact, no files in the directory (including the target directory) referenced the hash. But again, if I reloaded (because of a change or just by pressing Ctrl-R) it would revert to that hash, which didn't exist and result in a blank gray screen.

Since the file with that name didn't exist, it looks like trunk just served my index.html as text/html. This is what caused the first error message. It was trying to interpret my index.html as javascript, seeing that it was text/html, and refusing.

Following @amPerl's advice, I brought up the dev tools, selected the "Application" tab at the top, clicked on "Storage" (for me it was not selected by default), and then selected "Clear site data". I don't remember if I just reloaded or hard reloaded at that point, but then things started working.

I wasn't able to figure out where it was getting the bogus hash from, but based on @amPerl's comment, I guess the service worker must have a reference in a cache somewhere which the "Empty cache and Hard Reload" option on Chrome's reload button did not clear.

So far, the problem hasn't recurred, but I haven't done much testing (or much development) since the fix. If I figure out what triggered in the first place, I'll report back (though there's a lot I don't know about all of this, so we'll see if I can figure anything out).

I'm not sure what my original trunk version was, but I upgrade while debugging and it now reports 0.19.2.

Outside of the eframe_template directory, rustc reports:
$ rustc --version
rustc 1.77.2 (25ef9e3d8 2024-04-09)

In the eframe_template directory, it reports:
$ rustc --version
rustc 1.76.0 (07dca489a 2024-02-04)

(because of the rust-toolchain file).

I've been testing with eframe_template version: ab640be

Hope that helps.

[dehann]

Hi, more information that partially relates. Upon a fresh clone of this repo, I was not having success with trunk serve of the vanilla template site locally 127.0.0.1:8080. I would also get stuck on just the gray loading screen and spiny arrows. The F12 devtools --> Debugger panel would show problems with retrieving resources and unable to confirm sha384 for resources.

After much digging, I'm pretty sure my issues are related to the latest Firefox 128.0, and the "filehash" mentioned above, although I'm having some trouble pinning it down exactly (I'm not up to speed with everything needed here yet). I sort of got the site to load locally via a different solution from above and sharing since I was not finding the following information elsewhere:

In developer tools, under debugger the main error I keep getting is "NetworkError .. unable to load", this was likely due to no match on the SHA384 of embedded <script> _inline code_ </script> in index.html.

I tried but failed:

• F12, clear local storage/cookies and or Ctrl+R / Ctrl+F5.
• Faking the <script integrity=sha384-___ crossorigin="anonymous"> from the expected sha384.
• Moving the index.html inline script serviceWorker .. window.addEventListener('load'.. 'sw.js. ..) into a separate load.js and generating a integrity sha384, as per this dev example.
• Did not want to remove the security by allowing CORS from any and all subdomains.
• use of url #dev did not seem to change the behavior -- i.e. still didn't work.
• Compiling for Debug or Release didn't seem to change anything.
• A few related posts etc around the web when searching for related topics.

What did work

• I got varied results between Firefox Private mode or normal, sometimes the template site would load in private (could not see the pattern why), but definitely wouldn't load in normal mode.
  • This was at least partially related (but not 100%) to changing Firefox about:config --> security.enterprise_roots.enabled = true. I got different results depending, and this never worked for normal mode.
• I was always able to just open the site via the direct url: http://127.0.0.1:8080/eframe_template-3b95fdc63b82a9f0_bg.wasm, as per contents of the trunk built dist/ folder.
• Loading the website under IPv6, [::1]:8080 and hitting VSCode popup "trust this and subdomains for [::1]" -- from there IPv6 would always work. IPv4 would still not work after.
• Back on IPv4 in my case 127.0.0.1:8080 still using my load.js + sha384 attempt, under F12 devtools --> Application --> Service Workers I hit the Unregister button and it seems the site now loads fine every time. However the Service Worker no longer shows up (I don't understand exactly what changed yet):
  

Ubuntu 22.04, rustc 1.76.0, trunk 0.20.2, Firefox 128.0. Developing + using terminal from VSCode 1.91.1.

[0xtimsb]

solved by disabling filehash in Trunk.toml

[build]
filehash = false

[xjpch]

Sorry for being away for so long. In fact, I later used local development and then deployed it to the server, and it didn't have much impact.
And I can't reproduce this problem now.