ReviewOS

stacks/stx

SPA link interceptor resolves relative hrefs against location.origin (should be location.href) — relative ?query/#hash links jump to site root

#1777
Closed glennmichael123 opened this 10 days ago ·
10 days ago

Summary

stx's client-side SPA navigation (the data-stx-link click interceptor) resolves link targets against location.origin instead of the current document URL. As a result, relative links (query-only ?x=y, or fragment/relative paths) navigate to the origin root instead of resolving against the current page.

In the compiled runtime this shows up as:

new URL(url, location.origin)   // <-- base is the origin root, not the current URL

Reproduction

On a page served at /dashboard, a plain relative link:

<a href="?status=resolved">Resolved</a>

Clicking it navigates to /?status=resolved (the site root / landing page), not /dashboard?status=resolved. The same happens for any relative href that omits the path.

Expected

Relative links should resolve against the current document URL (standard <a> semantics), i.e. new URL(url, location.href). ?status=resolved on /dashboard should go to /dashboard?status=resolved.

Impact

Any app using relative links (filter tabs, pagination, ?sort=, #anchor) inside stx pages silently sends users to the wrong URL once the SPA interceptor is active — typically bouncing them to the site root. The workaround is to make every link absolute, but that's surprising and easy to miss.

Suggested fix

Resolve against location.href rather than location.origin in the link interceptor (and anywhere else a link/asset URL is resolved for navigation):

- new URL(url, location.origin)
+ new URL(url, location.href)

Found via bun-plugin-stx (dist) driving a Stacks app; happy to point at the exact minified sites if useful.

Sign in to comment on this issue.