Related issue #53996

Hi
@javiercn:
contrary to .net 8 using the NavigationManager.NavigateTo in an OnInitilized/Async (Blazor Server) is creating a runtime Error as it did up to .net 6 and now again in .net 9. Would you consider this to be treated with the same idea you proposed or do you think this is another type of problem ? Used this in .net 8 a lot without running into problems. Or just revert back to moving it to OnAfterRender and mange what is displayed before ? Which is cumbersome. Would be interested in your thoughts.

Sorry, I do not agree with the categorization of this issue as a feature request for .NET 10; its a bug in .NET 9. This behaviour is a breaking change from .NET 8 and was not documented to work in this fashion. This negates the existing SSR/prerendering modes for our App architecture, forcing us to make the whole app Interactive from the getgo increasing the latency of our first/landing page

@indcoder thanks for contacting us.

This behavior hasn't changed between .NET 8.0 and .NET 9.0.

During prerendering we've always thrown a NavigationException and triggered a re-render, even in the old Blazor Server model.

forcing us to make the whole app Interactive from the getgo

@indcoder could you please describe your previous and current experience in more detail ?
Are you talking about NavigationException ? Are you talking about behavior in VS debugger or something else ?

contrary to .net 8 using the NavigationManager.NavigateTo in an OnInitilized/Async (Blazor Server) is creating a runtime Error as it did up to .net 6 and now again in .net 9. Would you consider this to be treated with the same idea you proposed or do you think this is another type of problem ? Used this in .net 8 a lot without running into problems. Or just revert back to moving it to OnAfterRender and mange what is displayed before ? Which is cumbersome. Would be interested in your thoughts.

This behavior hasn't changed between 6,7,8 or 9. During prerendering, NavigationManager.NavigateTo has always thrown a NavigationException.

The purpose of this issue is to get rid of the NavigationException because it causes issues, and we want to make sure we align the behavior across different render modes.

Hi @pavelsavara @javiercn I encountered this issue circa Dec'24 when implementing IAM for the app. Searched on GH...and it was identical to Adam's experience adamfoneil/CardGameSDK#16 who also has referenced this issue. I didn't revert back to 8 nor take screenshots/video since ours was a relatively greenfield project but rather opted for global interactivity with prerendering disabled. And I only revisited this issue since Aspire 9.1 was about to be released.

This issue was always one of the caveats we had to give when folks try out Blazor and start implementing IAM https://x.com/hackmum/status/1878801401759043931, and I thought it was high enough in the priority to tackle it early. I am now reconciled to the fact that this will be solved only by the .NET 10 timeframe and I'm glad to see IAM story in Blazor getting a larger mindshare in .NET 10 @danroth27

Because the arduous workaround to adopt a minimally adequate security posture for Blazor Web App has been its Achilles heel for its adoption. Even the movie sample app that @guardrex references this issue does not implement IAM

Also, hopefully for .NET 10, while we are at it, the IAM chain is being holistically examined to make it frictionless for folks to secure their Blazor app across any combination of render modes, in the process jettisoning the remnants of .NET framework in the IAM chain e.g.: 👇

@indcoder thanks for the additional details.

It's unclear to us how what you are describing is related to this issue. If there's anything that you want to propose or that you have problems with, could you please file a separate issue describing the concrete problem that you are having and what you are proposing to that regard?

Thanks.

Also, there is one more inconsistency between the interactive modes and SSR, if I pass in a value of true for replace parameter, in case of SSR, it doesn't actually replace the current URL but navigates to the new URL leaving the previous one in the history.