Abort client-side navigation fetches when another link is clicked

[theetrain]

Describe the bug

On any SvelteKit site with default link settings (all links have data-sveltekit-preload-data), hovering a link will prefetch that link's page's data and then clicking will navigate after all data has been fetched.

However, after clicking on a different link before the previous link has completed, the previous click's fetch will continue to run. This does not free up memory and network resources for the user as they wait for their desired page to load.

Reproduction

1. Go to https://www.sveltelab.dev/ftydq4t92gq0r37
2. Open dev tools network inspector and filter by Fetch/XHR
3. Click on 'test' hyperlink, then immediately click on 'about' hyperlink
4. Observe both requests are completed even though the 'test' page is no longer needed to load

Logs

No response

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @sveltejs/adapter-auto: ^3.0.0 => 3.3.1 
    @sveltejs/kit: ^2.5.27 => 2.8.0 
    @sveltejs/vite-plugin-svelte: ^4.0.0 => 4.0.0 
    svelte: ^5 => 5.1.13 
    vite: ^5.4.4 => 5.4.10

Severity

annoyance

Additional Information

I think this can be addressed as a patch since cancelling unnecessary requests client-side will still complete their server-side load process to completion. If any applications depend on that behaviour, it shouldn't change.

Potentially out of scope is applying a similar 'abort' behaviour to goto and use:enhance for forms using <form method="GET">; though that's already solveable today in userland by providing wrappers.

Potentially related to

• Abortable PageLoad functions with AbortSignal #9637; in which case perhaps we can add control to link behaviour via a client-side hook. Regardless, I consider the problem outlined above as a bug.

[Conduitry]

Without asynchronous context in JS, I don't know how we'd know generally which asynchronous fetches were the result of the preload. At most, we'd be able to abort all of the fetches initiated synchronously as part of the preload. This might be enough - especially in +page.server.js situations, where there's only one fetch.

[theetrain]

I see that preloading occurs when tap gets called:

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

Lines 1531 to 1534 in 598129a

	function tap(event) {
	if (event.defaultPrevented) return;
	preload(/** @type {Element} */ (event.composedPath()[0]), 1);
	}

Maybe we can add an array to accumulate all preload events, and when the user clicks a link we can abort all preload calls except for the clicked link. Some napkin code: https://svelte.dev/playground/da6786a93dc9418098b64345f6d044a1?version=5.1.13

If using a map to keep track of preloaded links, then perhaps this can be configurable in the project with settings such as:

• Cancel preload on click: whether to cancel all other links still preloading data after a link has been clicked (default: true)
• Preload link tail limit: set maximum number of links to preload (default: unlimited/null; example: 3)
• Debounce preload timer: time in milliseconds before preloading data after mouseenter event starts without mouseleave (default: 0)