Different-origin link to same path incorrectly getting handled by client-side router

[robots4life]

Describe the bug

Installing the default Skeleton with JS or TS and clicking on the link to https://kit.svelte.dev does not work.

Reproduction

Cannot follow link https://kit.svelte.dev from deployed and/or local Sveltekit installation. This is pretty much the default skeleton installation with JS or TS.

https://daiki-six.vercel.app/

Logs

Firefox

Uncaught (in promise) DOMException: The operation is insecure. start-f3a65506.js:1
    ge https://daiki-six.vercel.app/_app/start-f3a65506.js:1
    AsyncFunctionThrow self-hosted:704
    (Async: async)
    _start_router https://daiki-six.vercel.app/_app/start-f3a65506.js:1

Chrome

start-f3a65506.js:1 Uncaught (in promise) DOMException: Failed to execute 'pushState' on 'History': A history state object with URL 'https://kit.svelte.dev/' cannot be created in a document with origin 'https://daiki-six.vercel.app' and URL 'https://daiki-six.vercel.app/'.
    at he (https://daiki-six.vercel.app/_app/start-f3a65506.js:1:13087)
    at async ge (https://daiki-six.vercel.app/_app/start-f3a65506.js:1:18752)

https://github.com/robots4life/daiki

Firefox http://localhost:3000

Uncaught (in promise) DOMException: The operation is insecure. start.js:623
    navigate http://localhost:3000/@fs/shared/httpd/daiki/.svelte-kit/runtime/client/start.js:1256
    AsyncFunctionThrow self-hosted:704
    (Async: async)
    _start_router http://localhost:3000/@fs/shared/httpd/daiki/.svelte-kit/runtime/client/start.js:1460

Chrome http://localhost:3000

start.js:623 Uncaught (in promise) DOMException: Failed to execute 'pushState' on 'History': A history state object with URL 'https://kit.svelte.dev/' cannot be created in a document with origin 'http://localhost:3000' and URL 'http://localhost:3000/'.
    at update (http://localhost:3000/@fs/shared/httpd/daiki/.svelte-kit/runtime/client/start.js:623:64)
    at async navigate (http://localhost:3000/@fs/shared/httpd/daiki/.svelte-kit/runtime/client/start.js:1241:3)

System Info

System:
    OS: Linux 5.4 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
    CPU: (8) x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
    Memory: 6.10 GB / 15.53 GB
    Container: Yes
    Shell: 5.1.4 - /bin/bash
  Binaries:
    Node: 17.4.0 - /opt/nvm/versions/node/v17.4.0/bin/node
    Yarn: 1.22.17 - /usr/bin/yarn
    npm: 8.3.1 - /opt/nvm/versions/node/v17.4.0/bin/npm
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.33 
    @sveltejs/adapter-node: ^1.0.0-next.73 => 1.0.0-next.73 
    @sveltejs/kit: next => 1.0.0-next.302 
    svelte: ^3.44.0 => 3.46.4

Severity

annoyance

Additional Information

Adding rel=external to the link makes it work.

Visit <a rel="external" href="https://kit.svelte.dev">kit.svelte.dev</a> to read the documentation

[Conduitry]

There's a larger issue going on here. What's in the skeleton app (and in the default demo app) should be fine. The router should notice that the link is to a different origin and not try to handle it with client-side SPA navigation - but that's not what's happening, and then the history API is (rightfully) complaining about us adding a history item with a different origin.

[Conduitry]

I think this was broken in #4334. After

kit/packages/kit/src/runtime/client/client.js

Line 200 in 2865f41

const intent = get_navigation_intent(url);

we should probably be checking whether intent is falsy and then calling native_navigation like we are down on

kit/packages/kit/src/runtime/client/client.js

Line 220 in 2865f41

await native_navigation(url);

[Conduitry]

Doing that's breaking tests. I think we need to call native_navigation only when it's on a different origin or outside the app's base path. Other undefined return values from get_navigation_intent indicate that this is an internal link that's a 404, which (I think) needs to be handled differently as per the check at

kit/packages/kit/src/runtime/client/client.js

Line 205 in 2865f41

if (!navigation_result && url.pathname === location.pathname) {

[Conduitry]

Aha! This case was already supposed to be handled by the code at

kit/packages/kit/src/runtime/client/client.js

Line 219 in 2865f41

if (!navigation_result) {

but this bug is specifically happening when we're linking to the same path on a different origin, because the branch at

kit/packages/kit/src/runtime/client/client.js

Line 205 in 2865f41

if (!navigation_result && url.pathname === location.pathname) {

is erroneously kicking in. (I'll update the issue title.)

I think the proper fix is to just additionally check url.origin === location.origin.