Forms PRG and error handling fixes

[SteveSandersonMS]

Fixes #47903 and #49143

Mostly it's just tweaks to the flow in RazorComponentEndpointInvoker, plus a ton of E2E cases.

Forms + streaming rendering

While doing this I realised the way we dispatch form events isn't as integrated into streaming SSR as I thought. What I thought would happen is:

• Initial synchronous render
• Streaming begins
  • Any series of further async renders until quiescence
  • Dispatch submit event
  • Any series of (possibly async) renders until quiescence

... but what actually happens is:

• Initial synchronous render
• Pause until quiescence, not doing any streaming during this time
• Dispatch submit event
• Streaming begins
  • Any series of (possibly async) renders until quiescence

So, it's not streaming until the submit event is dispatched. I tried fixing this but it involves more changes than I was ready to do just hours before the CC deadline. One particularly tricky bit is that the handling for returning 400 errors in the case of invalid/missing form names relies on the response not yet having started. If we are willing to do real streaming before we even get to the submit event dispatch, we also have to deal with the case where we then see it's an invalid submission but the response has already started.

We already handle "error after response already started" when it's an exception - we send a message over the SSR channel about it. Extending this to handle cases that aren't unhandled exceptions makes the flow more complex.

If we choose to do this in the future, the main aspects of the work are something like:

• Move the call to DispatchEventAsync inside BeginRenderingRootComponent.
  • BeginRenderingRootComponent should continue waiting only until the non-streaming tasks have completed and then return an HtmlRootComponent, but now it should represent the entire rest of the process including event dispatch. That way the upstream code doesn't have to differentiate all these cases.
  • To achieve that, we probably need some new protected API on StaticHtmlRenderer that waits for a supplied task (for which we'll pass the original quiescence task) and then dispatches an event and return an HtmlRootComponent with a QuiescenceTask representing quiescence after that event
  • Then, EndpointHtmlRenderer would return that instead of the original HtmlRootComponent
  • The tricky bit with "invalid submission" remains. The best I can think of is throwing some kind of new "InvalidFormSubmitException" that we then catch at the same level we'd catch NavigationException and convert that into a 400 (if the response hasn't started) or a new streaming SSR message (if it has)

That's not going to happen for preview 7 but we can consider whether it's important for RC1.

Update Great point from @javiercn below about why the user experience is better if we don't change this: #49472 (comment)

[SteveSandersonMS]

These unrelated renames are follow-up on code-review feedback from an earlier PR. Just trying to clear up!

[javiercn]

So, it's not streaming until the submit event is dispatched. I tried fixing this but it involves more changes than I was ready to do just hours before the CC deadline. One particularly tricky bit is that the handling for returning 400 errors in the case of invalid/missing form names relies on the response not yet having started. If we are willing to do real streaming before we even get to the submit event dispatch, we also have to deal with the case where we then see it's an invalid submission but the response has already started.

I don't think we should do streaming rendering before we dispatch the event. It will result in a very inconsistent experience if you try to alter the response in any way as part of the POST and there is not a ton of value for it. (You are not getting to the page for the first time nor getting new data to consume, you are waiting the results from an action you triggered).

[SteveSandersonMS]

It will result in a very inconsistent experience if you try to alter the response in any way as part of the POST and there is not a ton of value for it. (You are not getting to the page for the first time nor getting new data to consume, you are waiting the results from an action you triggered).

Great point. TBH I don't have a certain sense of there being important scenarios for streaming before dispatching the event, now you've made me think of it more clearly.

Happy to leave it as-is then.

[darena-pjindal]

Hello - Was the issue reported by Daniel in #49143 fixed in the latest release? I am still having that issue. Is there a workaround for this? The form code below crashes.
@page "/Test"
@Inject NavigationManager NavigationManager

Index

Hello, world!

Welcome to your new app.

Submit and navigate

@code {
void Navigate()
{
Console.WriteLine("Navigate");
NavigationManager.NavigateTo("/counter");
}
}

[ghost]

Hi @darena-pjindal. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[SteveSandersonMS]

@darena-pjindal Are you sure that code crashes? It works fine for me. Is it possible that it doesn't really crash, but you've got the VS debugger connected and it's telling you about first-chance exceptions instead?

[darena-pjindal]

Hi @SteveSandersonMS -
I get the following exception and am not able to debug it. It does work if I run without debugging. I need to be able to debug. Is there a setting that I have to choose for VS to ignore specific types of exceptions?

[ghost]

Hi @darena-pjindal. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[SteveSandersonMS]

Yes, see the checkbox in the screenshot labelled "break when this exception type is user-unhandled"

[darena-pjindal]

Ah ok. That made it work. Thank you so much.

[ghost]

Hi @darena-pjindal. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[julioct]

Hi @SteveSandersonMS Long time! Hey, I'm also getting the NavigationException in VS Code, as part of a tutorial I'm preparing for folks new to Blazor:

I don't think it is a good experience for folks new to the platform, and they should not need to mess around with code editor settings to work around such a simple scenario.

Is there anything that can be done to properly handle the exception in the runtime itself?

[siroman]

are you sure you are not mixing renderModes? i.e. you are trying to NavigateTo from a SSR mode page to an InteractiveServer one?

[julioct]

are you sure you are not mixing renderModes? i.e. you are trying to NavigateTo from a SSR mode page to an InteractiveServer one?

I'm sure. There's no interactivity enabled for this project. Pure SSR.

[julioct]

Got it, happens here:

    public void AddGameDetails()
    {
        DB.GameDetails.Add(GameDetails);
        NavigationManager.NavigateTo("/gamedetails");
    }

But does not happen here:

    public async Task AddGameDetails()
    {
        DB.GameDetails.Add(GameDetails);
        NavigationManager.NavigateTo("/gamedetails");
        await Task.CompletedTask;
    }

Created that with the Blazor scaffolder in VS.

In the async version I see this in the debugger logs:

Exception thrown: 'Microsoft.AspNetCore.Components.NavigationException' in Microsoft.AspNetCore.Components.Endpoints.dll

...but the debugger does not break into the exception and the app happily continues to the next page.

[SteveSandersonMS]

Hey @julioct!

Is there anything that can be done to properly handle the exception in the runtime itself?

I'm afraid the exception already is properly handled in the runtime itself. That's why the app "happily continues to the next page".

The issue is just that the debugger is being very proactive about telling you about an internal implementation detail of the framework (this exception). People don't need to know about this, so it's unfortunate it shows up on the log there.

Longer term we might change how the navigation is signalled to avoid this sort of weirdness. Nobody really likes using an exception here, but we did it to recreate the same semantics that happen on other platforms. We may decide that allowing the app code to continue executing even after the redirection is acceptable, and then would not need to use the exception.

[julioct]

Sounds good, thank you Steve!

[zarna-flywheel]

Interestingly, if I wrap

 NavigationManager.NavigateTo("/account");
 await Task.CompletedTask;

in a try-catch block, the redirection does not happen (as it hits the catch block).

Any insights on how I can get this to work in a try-catch block correctly?

[SteveSandersonMS]

Any insights on how I can get this to work in a try-catch block correctly?

Don't catch System.Exception (instead, catch the subclass that you're planning to deal with). Or if you must do that, then check if the exception you caught is NavigationException, and if it is, use throw;' to rethrow it.

[mohiyo]

@SteveSandersonMS I have a Login Form inside a Blazor Server App which is working fine with built-in functionality.
But now I am trying to solve a problem where I will be allowing Users to log in automatically when they reach from certain URL and with certain parameters, Without submitting a form

I tried this in my Login Component

protected override async Task OnInitializedAsync() {
  try {
    if (HttpMethods.IsGet(HttpContext.Request.Method))
      await HttpContext.SignOutAsync();

    if (parameter && condition) {
      await DirectLogin();
    }
  } catch (Exception ex) {
    _logger.LogError(message: ex.Message);
  }
}

async Task DirectLogin() {
  try {
  //Perform some logic here and then SignIn

    await HttpContext.SignInAsync(principal, new AuthenticationProperties {
      ExpiresUtc = DateTimeOffset.UtcNow.AddMinutes(5)
    });

    _navigation.NavigateTo($"/direct/page/{parameter}", true);
    //Here I get this exception "Microsoft.AspNetCore.Components.NavigationException"

  } catch (Exception ex) {
    errorMessage = $ "Error: {ex.Message}";
    _logger.LogError(message: ex.Message);
  }
}

This login Component is in a Static Server Render mode whereas after the successful SignIn, the User will be redirected to an Interactive Server Component.

But Navigation is not working and I am getting this exception

Exception of type 'Microsoft.AspNetCore.Components.NavigationException' was thrown

[javiercn]

@mohiyo please don't comment on closed PRs.

File a separate issue instead. What's likely happening is that you are breaking on first chance exceptions. NavigationException is thrown by the framework to trigger an SSR navigation, but it's caught internally. If you have a try..catch you should avoid capturing NavigationException.