InMemoryNavigationProvider<T> drops a legitimately-null current destination from history

[matt-edmondson]

What's wrong

InMemoryNavigationProvider<T>.NavigateTo, GoBack, and GoForward (Essentials.NavigationProviders.InMemory/InMemoryNavigationProvider.cs:49-51, 70-72, 93-95) guard pushing the current destination onto the back/forward stack with if (Current is not null). For INavigationProvider<string> or any other nullable T where null is a legitimate navigation destination (e.g. a "no selection" state), this conflates "no current destination has been set yet" with "the current destination happens to be null", and silently drops that step from history.

Failure scenario

provider.NavigateTo("a");
provider.NavigateTo(null);   // legitimate destination, pushes "a" fine
provider.NavigateTo("b");    // Current is null here, so the null step is never pushed
provider.GoBack();           // returns "a" directly, skipping the null entry entirely

The null-destination step vanishes from history instead of being the immediate previous page.

Suggested fix

Track "has a current destination been set" with an explicit bool hasCurrent flag (or a nullable-aware sentinel) instead of testing Current is not null, so a legitimately-null Current is still pushed onto the stacks.

Acceptance criteria

A test using InMemoryNavigationProvider<string?> (or similar) that navigates through a null destination and calls GoBack/GoForward observes the null step in history rather than skipping it.

[matt-edmondson]

Triage

Category: Bug
Priority: Medium
Area: Essentials.NavigationProviders.InMemory — InMemoryNavigationProvider<T>

Medium rather than High because the blast radius is narrower than #30's: it only bites when T is nullable and null is a meaningful destination (a "no selection" state). Consumers navigating between non-null pages never see it. But within that case it is a silent correctness bug — history quietly loses a step, and GoBack returns the wrong destination with no error to signal it.

The root cause is the same conflation as #30 in this repo: is not null used as a proxy for "has a value been supplied", which stops being true the moment null is a legitimate value.

Suggested assignment: whoever owns the Essentials navigation providers.

Duplicates: none. Same theme as #30 (cache provider treating cached null as absent) but a separate component and separate fix — they should land independently. Since the pattern has now surfaced twice in this library, a sweep for other is not null presence-checks in Essentials is worth folding into whichever lands second.

Open PR covering this: none.

Suggested next step: the explicit bool hasCurrent flag from the issue body is the clearer of the two options offered — a nullable-aware sentinel reintroduces the same ambiguity one layer down. Note that all three call sites (NavigateTo, GoBack, GoForward) carry the guard, so the fix has to cover the pair of stacks consistently or history will desynchronise in a subtler way than it does now.

---

Generated by Claude Code