running prod.sh webpage is stuck in "loading..."

[malaire]

When running prod.sh and going to http://localhost:8080/ the webpage stays at "loading..."

Console shows following output:

...
2022-08-21T07:46:55.851388Z  INFO server: listening on http://[::1]:8080    
2022-08-21T07:47:02.368106Z DEBUG request{method=GET uri=/ version=HTTP/1.1}: tower_http::trace::on_request: started processing request
2022-08-21T07:47:02.368345Z DEBUG request{method=GET uri=/ version=HTTP/1.1}: tower_http::trace::on_response: finished processing request latency=0 ms status=200
2022-08-21T07:47:02.424372Z DEBUG request{method=GET uri=/assets/frontend-6f8d53fa38d70403_bg.wasm version=HTTP/1.1}: tower_http::trace::on_request: started processing request
2022-08-21T07:47:02.424887Z DEBUG request{method=GET uri=/assets/frontend-6f8d53fa38d70403_bg.wasm version=HTTP/1.1}: tower_http::trace::on_response: finished processing request latency=0 ms status=200
2022-08-21T07:47:02.425059Z DEBUG request{method=GET uri=/assets/frontend-6f8d53fa38d70403.js version=HTTP/1.1}: tower_http::trace::on_request: started processing request
2022-08-21T07:47:02.426817Z DEBUG request{method=GET uri=/assets/frontend-6f8d53fa38d70403.js version=HTTP/1.1}: tower_http::trace::on_response: finished processing request latency=1 ms status=200

There are no errors or messages in JavaScript console and I don't know how to debug why this isn't working.

OS: Debian 11
Browser: Firefox ESR 91.12.0esr

[rksm]

I'm not aware of any problems but a few things you might try:

• does running with ./dev.sh make a difference?
• does recompiling from scratch help?

rm -rf ./dist
rm -rf server/target
rm -rf frontend/target

• in your browser network tab you should see:
  
  and the console tab should show no errors, is this the case?

[rksm]

Also the version of Firefox you are running is a year old. If the above doesn't help I would try to update. Wasm support is still actively developed.

[malaire]

Running ./dev.sh works:

But ./prod.sh doesn't work:

Recompiling from scratch doesn't change anything. Javascript console has no errors and Browser console has this error for both ./dev.sh and ./prod.sh so this doesn't seem relevant:

This Firefox version is the newest available in Debian Stable repository.

[malaire]

If I remove --release from line trunk build --release --public-url /assets/ then ./prod.sh does work.

[rksm]

Yeah strange. One way to debug this is to put a breakpoint into the auto-generated init() function of /assets/frontend-*.js in your browser's debugger and then step through it to see where things stop working.

And just in case the last error is the cause. Try removing the <link rel="shortcut icon"type="image/x-icon" href="data:image/x-icon;,"> from index.html. Maybe FF is thrown off by that.

But generally that seems to be a browser issue, in particular with the FF version you are using. I have tested the example successfully with FF 103 on Linux, macOS and Windows.

[malaire]

Yeah strange. One way to debug this is to put a breakpoint into the auto-generated init() function of /assets/frontend-*.js in your browser's debugger and then step through it to see where things stop working.

When using ./prod.sh with trunk build --public-url /assets/, i.e. without --release, the "loading..." text is replaced with "Hello Frontend" during wasm.__wbindgen_start() call in finalizeInit.

function finalizeInit(instance, module) {
    wasm = instance.exports;
    init.__wbindgen_wasm_module = module;
    cachedFloat64Memory0 = new Float64Array(wasm.memory.buffer);
    cachedInt32Memory0 = new Int32Array(wasm.memory.buffer);
    cachedUint32Memory0 = new Uint32Array(wasm.memory.buffer);
    cachedUint8Memory0 = new Uint8Array(wasm.memory.buffer);

    wasm.__wbindgen_start();
    return wasm;
}

With unmodified ./prod.sh, i.e. with trunk build --release --public-url /assets/, there is no such wasm.__wbindgen_start() call and "loading..." text remains in the screen:

function finalizeInit(instance, module) {
    wasm = instance.exports;
    init.__wbindgen_wasm_module = module;
    cachedFloat64Memory0 = new Float64Array(wasm.memory.buffer);
    cachedInt32Memory0 = new Int32Array(wasm.memory.buffer);
    cachedUint32Memory0 = new Uint32Array(wasm.memory.buffer);
    cachedUint8Memory0 = new Uint8Array(wasm.memory.buffer);


    return wasm;
}

[malaire]

And just in case the last error is the cause. Try removing the <link rel="shortcut icon"type="image/x-icon" href="data:image/x-icon;,"> from index.html. Maybe FF is thrown off by that.

No change in behaviour, except I now get request for favicon and then different error about it, but otherwise same behaviour (i.e. works without --release and doesn't work with --release):

I have tested the example successfully with FF 103 on Linux, macOS and Windows.

I don't think I'm able to test that as I don't think it's possible to install newer FF alongside my current one so that newer doesn't touch any data of my current FF - they both would use same config directory and possibly destroy my current user data.

ps. Looks like Firefox ESR 91 hits EOL in 1 month, so Debian Stable should update to Firefox ESR 102 soon.

[rksm]

Hey, thank you for testing and investigating. Having the output differ is really strange and seems to be what the issue is. I can currently only test on macOS but I get the same finalizeInit on both dev and release build.

I've pushed a change, modifying the setup (using a cargo workspace) and using a separate CARGO_TARGET_DIR for the trunk build. Could see if this makes a difference (maybe run first the clean.sh script to get rid of the old build dirs). I have seen trunk stomping over the server build before but thought this is fixed. Maybe your issue is not related but it is worth a try.

[malaire]

Could be related if it's target dir issue as I have set a global absolute path for target dir (and to counter that I've lately used local build.target-dir = "target" in frontend and server to reset target dir to default.) I'll need to test some variations of these settings ...

[malaire]

target-dir setting wasn't the problem, the problem was my global profile.release.strip = true setting.

Adding file frontend/.cargo/config with profile.release.strip = false fixed this for me, both with latest commit and also without it.

[malaire]

ok, it's this bug: rust-lang/rust#93294

Closing as this is a known bug in wasm-bindgen.

[rksm]

Interesting, I had no idea. Thanks for following up on that, I'll update the guide.