sveltekit can't handle routing links inside element with on:click|stopPropogation

[ZerdoX-x]

Describe the bug

Popular usecase - Dialog component with backdrop implemented like this:

<div on:click={closeDialog} class="dialog-wrapper">
  <div on:click|stopPropagation class="dialog-content">
    <!-- dialog content -->
    <slot />
  </div>
</div>

But in this case it's impossible to use routing links inside this component. Instead it will be just regular native links with page refresh.

Reproduction

ZerdoX-x/-sveltejs-kit-5319

I placed button with incrementer so you can see if page refreshes.

Logs

No response

System Info

System:
    OS: macOS 12.2.1
    CPU: (8) arm64 Apple M1
    Memory: 102.27 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 17.7.1 - /opt/homebrew/bin/node
    Yarn: 1.22.15 - /opt/homebrew/bin/yarn
    npm: 8.5.2 - /opt/homebrew/bin/npm
  Browsers:
    Chrome Canary: 105.0.5148.0
    Firefox Developer Edition: 102.0
    Safari: 15.3
    Safari Technology Preview: 15.4
  npmPackages:
    @sveltejs/adapter-auto: 1.0.0-next.52 => 1.0.0-next.52 
    @sveltejs/adapter-static: ^1.0.0-next.34 => 1.0.0-next.34 
    @sveltejs/kit: 1.0.0-next.355 => 1.0.0-next.355 
    svelte: ^3.44.0 => 3.48.0

Severity

serious, but I can work around it

Additional Information

In case you have the same code I presented above, just create another .dialog-backdrop next to .dialog-content, style it properly and listen for click on backdrop. That's how I workarounded it! Maybe it will be harder or impossible if you use libraries or in some other cases. I would recommend creating link component like this:

<a
  href="{href}"
  on:click="{(event) => goto(event.currentTarget.href)}"
  {...$$restProps}
>
  <slot />
</a>

[Conduitry]

This feels like, at most, something to document. We're currently handling clicking via a single click listener on the window, and we don't want to traverse the DOM and attach listeners to each individual anchor element just in case someone's stopped click propagation.

[Rich-Harris]

Closing in favour of #4347, which suggests a possible solution (or at least mitigation)