Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
malaire opened this issue Aug 21, 2022 · 12 comments
Closed

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

malaire opened this issue Aug 21, 2022 · 12 comments

Comments

@malaire
Copy link

malaire commented Aug 21, 2022

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
Copy link
Owner

rksm commented Aug 21, 2022

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:
    image
    and the console tab should show no errors, is this the case?

@rksm
Copy link
Owner

rksm commented Aug 21, 2022

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
Copy link
Author

malaire commented Aug 21, 2022

Running ./dev.sh works:

dev

But ./prod.sh doesn't work:

prod

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:

error

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

@malaire malaire changed the title running prod.js webpage is stuck in "loading..." running prod.sh webpage is stuck in "loading..." Aug 21, 2022
@malaire
Copy link
Author

malaire commented Aug 21, 2022

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

@rksm
Copy link
Owner

rksm commented Aug 22, 2022

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
Copy link
Author

malaire commented Aug 22, 2022

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
Copy link
Author

malaire commented Aug 22, 2022

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):

favicon-error

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
Copy link
Owner

rksm commented Aug 23, 2022

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
Copy link
Author

malaire commented Aug 24, 2022

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
Copy link
Author

malaire commented Aug 28, 2022

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
Copy link
Author

malaire commented Aug 28, 2022

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

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

@malaire malaire closed this as completed Aug 28, 2022
@rksm
Copy link
Owner

rksm commented Aug 28, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants