URLs cannot safely be stored in search parameters

[djrenren]

Which project does this relate to?

Router

Describe the bug

When a url-encoded string (for example, a continue URL on login pages) is provided as a search parameter, it is forcibly unescaped on parse.

For URLs that do not include escaped characters such as / (%2F), ? (%3F), or # (%23), this is totally fine. But this forced unescaping can change the structure of the URL:

If I navigate with:

navigate({
  to: "someRoute",
  search: {
    continueUrl: "/foo%2Fbar"
  }
})

Then someRoute's validateSearch callback will be called with: { continueUrl: "/foo/bar" }. Which is a meaningfully different
Similarly strings like /foo%23bar become /foo#bar.

The result is that URL's cannot safely be passed around through search parameters, because tanstack will not preserve the value.

Your Example Website or App

https://stackblitz.com/edit/github-mxsrykd3?file=src%2Froutes%2Findex.tsx

Steps to Reproduce the Bug or Issue

1. Click the first link (/foo%23bar)
2. See that the received URL Param is /foo#bar.
3. Go back to main
4. Click the second link (/foo#bar)
5. See that the receive URL Param is /foo#bar.

You can also note that the encodings differ.

The encoding for the first link is: ?continueUrl=%2Ffoo%2523bar
The encoding for the second link is: ?continueUrl=%2Ffoo%23bar

So for some reason TSR is double decoding in the first case when it should just decode once.

Expected behavior

As a user, I expect to see my search param value to be retained. Clicking on the first link should display: { "continueUrl": "/foo%23bar"} instead of { "continueUrl": "/foo#bar"}.

Screenshots or Videos

No response

Platform

All platforms

Additional context

No response

[djrenren]

I believe the issue is here:

router/packages/router-core/src/qss.ts

Lines 47 to 49 in c0a6050

	const str = hasUriEncodedChars(mix)
	? decodeURIComponent(mix)
	: decodeURIComponent(encodeURIComponent(mix))

Since mix has already come from URLSearchParams, it has already been URL decoded. this code decodes it again which I'm sure helps in cases where users (or the library itself) accidentally double-encode something, but it's responsible for this behavior.

[djrenren]

Confirmed fixed v1.120.15. ty @vcarel