goto() fails if conditional

[Proziam]

Describe the bug

Using Tauri to build a desktop application I noticed that goto() doesn't work whenever it's called upon conditionally. If you put a console.log() above it, the console.log() does fire, and returns the expected value to indicate that goto() should also fire.

I found a workaround on reddit: setTimeout(() => goto('/profile/name'), 0); which does work.

Reproduction

Apologies for the lack of proper reproduction. You can find other users describing the issue in this thread along with a code sample: https://www.reddit.com/r/sveltejs/comments/10o7tpu/sveltekit_issue_goto_not_working_on_ios/

WORKS

    function formValid() {
        let title = <HTMLInputElement>document.getElementById('title');

        if (title.checkValidity()) {
            console.log(true);
                // This hack works. If you remove it, the goto() will not work.
                    setTimeout(() => goto('/profile/name'), 0);
        }
    }

DOES NOT WORK

    function formValid() {
        let title = <HTMLInputElement>document.getElementById('title');

        if (title.checkValidity()) {
            console.log(true);
            goto('/profile/name');
        }
    }

Logs

No errors are shown, console.log() tests all show that the code is functioning as intended.

System Info

System:
    OS: Windows 10 10.0.22621
    CPU: (32) x64 AMD Ryzen 9 7950X 16-Core Processor
    Memory: 52.81 GB / 63.14 GB
  Binaries:
    Node: 18.16.1 - C:\Program Files\nodejs\node.EXE
    npm: 9.8.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.22621.1992.0), Chromium (115.0.1901.183)
    Internet Explorer: 11.0.22621.1
  npmPackages:
    @sveltejs/adapter-auto: ^2.0.0 => 2.1.0
    @sveltejs/adapter-static: ^1.0.0-next.50 => 1.0.0-next.50
    @sveltejs/kit: ^1.20.4 => 1.22.3
    svelte: ^4.0.5 => 4.0.5
    vite: ^4.4.2 => 4.4.4

Severity

serious, but I can work around it

Additional Information

No response

[themajashurka]

Just curious, does calling await tick() (imported from svelte) before goto solves your problem?

[netaisllc]

@Proziam FYI for our app, Kit version 1.22.6 the problem you describe occurs even when outside of a conditional block, and your workaround still cures it.

What is very odd is that we've been using SvKit since before 1.0 and have many, many uses of goto. This feels like a regression of some sort.

@themajashurka For us, the tick based workaround does not work. The problem persists.

[Proziam]

@themajashurka When I was debugging this on our app tick didn't solve the issue.

@netaisllc I tested out most of the "solutions" I found when I was trying to debug this and the one I posted is the only one that worked on every test case I wrote. I haven't seen this issue outside of a conditional block yet though, so my app clearly isn't covering all the test cases.

I agree, this feels like a weird regression.

[Proziam]

This issue still persists on the latest version of svelte/kit (2.5.5)

Symptoms unchanged, still doesn't throw an error of any sort.

Still fixing the issue with:

export const navigate = (url: string) => {
  setTimeout(() => goto(url), 0);
}

[eltigerchino]

I've never used Tauri before and have no idea how it works. It would be very helpful if you provide a minimal reproduction so that it's possible to diagnose the issue.

[Proziam]

I've spent the last hour or so trying to make a repro without success. However, symptoms seem consistent with those described in this issue - https://github.com/sveltejs/svelte/issues/6732. FWIW, we've run into all of the same issues described in that thread, particularly with stores.

As for what Tauri is, it's running npm run build and then simply serving the website through the OS's native browser to make it function like a desktop app.

[zigenis]

Also experiencing this issue. goto() has been used many times in my app so far and has worked fine up until just now. I've cleared every cache known to man, deleted .svelte-kit + node_modules and started fresh. Nothing fixes it except the janky setTimeout workaround.

Edit: Nginx was caching it. Shame on me.