Blazor SSR chooses RemoteNavigationManager or HttpNavigationManager unpredictably

[SteveSandersonMS]

Current behavior:

• If you don't have AddServerComponents(), then your SSR components will use HttpNavigationManager
• If you do, then both SSR and interactive (server) components will use RemoteNavigationManager

Expected:

• Regardless of service registrations, the DI scope for SSR components should use HttpNavigationManager while the DI scope for interactive (server) components should use RemoteNavigationManager

Or in other words, SSR components currently select between the two implementations based on an entirely unrelated fact (whether or not your app is configured to support interactive server components), which is problematic.

This shouldn't currently impact the developer experience or behavior. However it might do, since the two implementations are quite different, and might vary behavior. This was actually the root cause of bug #49670, in the sense that E2E tests said the feature already worked, but that was only true for apps with AddServerComponents().

Longer term we should avoid the risk of inconsistency and similar bugs by ensuring we always use the SSR service for SSR scopes.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

We're not sure if this is a real issue. It's not like the behavior is non-deterministic. It is just we want to consistently use the right service depending on the rendering mode.