Fix Issue with decoding URLs

[labkey-nicka]

Rationale

This addresses #10814 by switching from using safelyDecodeURI() to using safelyDecodeURIComponent() in matchRoutes(). The reason using decodeURIComponent is necessary is because it does not assume is is operating on a full URI. From MDN:

decodeURI assumes the input is a full URI, so it does not decode characters that are part of the URI syntax.

The result is when decodeURI it can lead to portions of the string not being decoded properly.

Example

This example shows what is currently happening when decodeURI is used and is borrowed from #11109:

// Route definition
<Route path=":myParam" element={<MyPage />} />

// In MyPage
const myParam = useParams().myParam;
console.log(myParam);

Then navigate to the following URL: /bad%20%26%20encoding%20%25%20here

Expected: The parameter should be decoded and "bad & encoding % here" is logged.
Actual: The parameter is not decoded properly and "bad %26 encoding % here" is logged.

This PR fixes this and adds regression tests.

Changes

• Switch matchRoutes() utility to use safelyDecodeURIComponent().
• Only decode the pathname once rather than per call to matchRouteBranch as the pathname does not change.
• Update tests to ensure coverage of decoding behavior.
• Update safelyDecodeURIComponent to optionally take the paramName argument.
• Removes safelyDecodeURI as this utility is no longer used. Happy to walk this back if the maintainers feel different about leaving code like this around.
• Fix a typo.

[changeset-bot]

🦋 Changeset detected

Latest commit: b242c77

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages

Name	Type
react-router	Patch
@remix-run/router	Patch
react-router-dom	Patch
react-router-dom-v5-compat	Patch
react-router-native	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[remix-cla-bot]

Thank you for signing the Contributor License Agreement. Let's get this merged! 🥳

[labkey-nicka]

While this may seem odd I think it is cleaner then trying to refactor the regular expressions generated by compilePath() to handle "//". This should maintain backwards compatibility support for #8072 in light of the new decoding strategy introduced by this PR. @mjackson I'd appreciate it if you could take a look since you're familiar with this issue and the matching semantics in general.

[brophdawg11]

Thank you for the PR @labkey-nicka! I had actually also been looking into this and had a local branch with some changes that I finally got completed and pushed up in #11199 so I'm going to close this one. I think this approach also had some minor issues with descendant routes and the way we do the remainingPathname/parentPathnameBase stuff which should be handled by the approach in #11999 as well.