Antiforgery state doesn't always reach interactive components

[SteveSandersonMS]

Repro:

• Create a Blazor Web App with global WebAssembly interactivity, and "include sample pages"
• Edit Counter.razor to include a form

<form method="post">
    <AntiforgeryToken />
</form>

• Launch the app
• Verify that if you first land on the homepage, then do a client-side navigation to Counter, that the form does not contain any __RequestVerificationToken hidden field (see this using the DOM inspector)
• Now reload the page while you're on Counter, so that's where you first land. Verify that the form does contain the __RequestVerificationToken hidden field. Even if you navigate away and back interactively, it will still be there

This inconsistency can't be desirable. Whether or not there's an antiforgery token shouldn't depend on which page you first arrived at.

Also note this is not a matter of prerendering. The exact same problem still occurs even if you disable prerendering.

You can work around it by adding <AntiforgeryToken /> into your layout. The fact that this workaround works suggests that the problem is:

• We only use the persisted component state during the first WebAssembly render cycle
• If there isn't an <AntiforgeryToken /> on the first WebAssembly render cycle, the persisted antiforgery state just gets discarded

I guess we could special-case things for antiforgery by ensuring the WebAssembly renderer always reads that state on the first render. Not sure if an equivalent problem could occur for other persistent component state (perhaps not, because app-specific persistent state would only exist if a component is prerendered to emit it, and then the same component should occur during the WebAssembly startup to collect that state - so maybe this bug is just unique to antiforgery data).

[SteveSandersonMS]

Note that this can also affect interactive Server components too, as shown by dotnet-smartcomponents/smartcomponents#14