[Bug]: NavLink active breaks when to contains trailing slash

[njdancer]

What version of React Router are you using?

6.10.0

Steps to Reproduce

Create a NavLink with end omitted or set to false and with to set to a route path which contains subroutes and ensure a trailing slash at the end.

Visit a subroute of the path in use.

Expected Behavior

With end false, when the current location is a subroute of a mounted NavLink, then it should be active.

Actual Behavior

NavLink is considered inactive.

This seems to be a result of the following line:

react-router/packages/react-router-dom/index.tsx

Line 576 in f397ad7

locationPathname.charAt(toPathname.length) === "/");

Currently, when end false and the current location startsWith(to), we are checking if the next unmatched character is a / to ensure the last segment wasn't only a partial match. This however is done assuming that to didn't already have a trailing slash which is not currently guaranteed to be the case. As such when it does contain a trailing slash it ends up comparing against the following character.

Unfortunately I could not create a repro via StackBlitz as the template was giving me an esbuild error at the time. Happy to provide this if StackBlitz starts working again.

[iamdey]

We have the same issue with:

<Navlink to="/">App</Navlink>

This link should be always active (since end is not true)

I've manage to reproduce and tried to describe expected behavior, cf. Layout component:

https://stackblitz.com/edit/github-1aweyn?file=src%2FApp.tsx

(Tell me if it's not clear enough).

And I also suspect locationPathname.charAt(toPathname.length) === "/"); to be responsible of this:

when /something and to="/":

• toPathname.length is 1
• locationPathname.charAt(1) is s

when /something/happend and to="/something/:

• toPathname.length is 11
• locationPathname.charAt(11) is h

Well with 6.4 after the fix it doesn't seem to be possible to have both cases (active or inactive according to end).

[yanndinendal]

See also #9261 (comment):
because of this issue, the doc seems to be wrong.

[bilalk711]

@ryanflorence I have fixed this issue for dev
#10734

[bilalk711]

@brophdawg11 #10734

[bilalk711]

@timdorr can you review my PR please?

[brophdawg11]

This is resolved in via #10734 and will be available in the next release