Fix Blazor persistent component state restoration for components without keys and add E2E test coverage

[Copilot]

The _ignoreComponentPropertyValue flag in PersistentValueProviderComponentSubscription was only being set conditionally within if (!skipNotifications) blocks, causing restored values to be ignored when components are destroyed and re-added during navigation or when components don't use @key.

Problem

When a component is added, removed, then added again (for example, during page navigation or when a component doesn't use @key), the restored value from persistent state storage was being ignored. This happened because:

1. During initial component setup, skipNotifications is often true
2. The _ignoreComponentPropertyValue = true assignment was inside the if (!skipNotifications) block
3. Without this flag set, GetOrComputeLastValue() would return the component's current property value instead of the restored value

Solution

Moved _ignoreComponentPropertyValue = true; outside the conditional blocks so it's set unconditionally whenever we successfully restore from persistent state. This ensures that the restored value always takes precedence over the component's initial property value, regardless of notification settings.

Before:

if (!skipNotifications)
{
    _ignoreComponentPropertyValue = true;
    _subscriber.NotifyCascadingValueChanged(ParameterViewLifetime.Unbound);
}

After:

_ignoreComponentPropertyValue = true;
if (!skipNotifications)
{
    _subscriber.NotifyCascadingValueChanged(ParameterViewLifetime.Unbound);
}

Test Coverage

Added comprehensive test coverage including:

Unit Tests

• Enhanced existing unit tests to properly simulate cascading parameter behavior
• Added debug test to verify the _ignoreComponentPropertyValue flag behavior
• Fixed test timing issues by ensuring proper state consumption patterns

E2E Tests

Following feedback from @javiercn, added E2E test infrastructure for two critical scenarios:

1. PageWithConditionalPersistentComponents.razor - New test page supporting:

   • Component without @key that always renders (tests navigation scenarios)
   • Component conditionally rendered based on query parameters (tests add/remove scenarios)

2. StatePersistenceTest.cs - New E2E tests covering:

   • CanRestoreStateForComponentsWithoutKeysAndConditionalRendering - Validates both components restore state correctly
   • CanRestoreStateAfterConditionalComponentToggling - Tests state restoration after component toggling

The E2E tests use query string parameters to control component rendering and validate that persistent state works correctly in all scenarios where components are dynamically added/removed, particularly during enhanced navigation in Blazor applications.

Fixes #63193.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[dotnet-policy-service]

Greetings human! You've submitted a PR that modifies code that is shared with https://github.com/dotnet/runtime . Please make sure you synchronize this code with the changes in that repo!

[javiercn]

@copilot

    [Fact]
    public async Task GetOrComputeLastValue_FollowsCorrectValueTransitionSequence()
    {
        // Arrange
        var appState = new Dictionary<string, byte[]>();
        var manager = new ComponentStatePersistenceManager(NullLogger<ComponentStatePersistenceManager>.Instance);
        var state = manager.State;
        var serviceProvider = PersistentStateProviderServiceCollectionExtensions.AddSupplyValueFromPersistentComponentStateProvider(new ServiceCollection())
            .AddSingleton(manager)
            .AddSingleton(manager.State)
            .AddFakeLogging()
            .BuildServiceProvider();
        var renderer = new TestRenderer(serviceProvider);
        var provider = (PersistentStateValueProvider)renderer.ServiceProviderCascadingValueSuppliers.Single();
        var component = new TestComponent { State = "initial-property-value" };
        var componentId = renderer.AssignRootComponentId(component);
        var componentState = renderer.GetComponentState(component);
        // Pre-populate the state with serialized data
        var key = PersistentStateValueProviderKeyResolver.ComputeKey(componentState, nameof(TestComponent.State));
        appState[key] = JsonSerializer.SerializeToUtf8Bytes("first-restored-value", JsonSerializerOptions.Web);
        await manager.RestoreStateAsync(new TestStore(appState), RestoreContext.InitialValue);
        await renderer.Dispatcher.InvokeAsync(() => renderer.RenderRootComponentAsync(componentId, ParameterView.Empty));
        var cascadingParameterInfo = CreateCascadingParameterInfo(nameof(TestComponent.State), typeof(string));
        // Act & Assert - First call: Returns restored value from state
        Assert.Equal("first-restored-value", component.State);
        // Change the component's property value
        component.State = "updated-property-value";
        // Second call: Returns the component's property value
        var result2 = provider.GetCurrentValue(componentState, cascadingParameterInfo);
        Assert.Equal("updated-property-value", result2);
        appState.Clear();
        var newState = new Dictionary<string, byte[]>
        {
            [key] = JsonSerializer.SerializeToUtf8Bytes("second-restored-value", JsonSerializerOptions.Web)
        };
        // Simulate invoking the callback with a value update.
        await renderer.Dispatcher.InvokeAsync(() => manager.RestoreStateAsync(new TestStore(newState), RestoreContext.ValueUpdate));
        Assert.Equal("second-restored-value", component.State);
        component.State = "another-updated-value";
        // Other calls: Returns the updated value from state
        Assert.Equal("another-updated-value", provider.GetCurrentValue(componentState, cascadingParameterInfo));
        component.State = "final-updated-value";
        Assert.Equal("final-updated-value", provider.GetCurrentValue(componentState, cascadingParameterInfo));
        Assert.Equal("final-updated-value", provider.GetCurrentValue(componentState, cascadingParameterInfo));
    }
    ```
    You must write the tests following this approach, but note that the main difference here is that the subscription will be re-created (because it will be a new component) in between each state restoration

[Copilot]

I've rewritten the tests following your guidance to properly simulate component recreation scenarios where subscriptions are re-created between state restorations. The new tests use the full renderer setup like GetOrComputeLastValue_FollowsCorrectValueTransitionSequence() and properly simulate:

1. Component creation with initial state restoration
2. Component destruction using RemoveRootComponent()
3. Component recreation with new subscription instances
4. Verification that restored values are preserved correctly across these recreations

The tests now accurately reflect the real-world scenarios where components are destroyed and recreated during navigation or when components don't use @key. Fixed in f54388f.

[javiercn]

@copilot

We should look at the E2E test cases in #62824 to add also support for these other two scenarios.

Specifically src/Components/test/E2ETest/Tests/StatePersistenceTest.cs and src/Components/test/testassets/Components.TestServer/RazorComponents/Pages/PersistentState/PageWithDeclarativeEnhancedNavigationPersistentComponents.razor

Our test could be designed to use a query string to choose to render or not render the components. There would be one component without a key that renders always and a component that gets added/removed depending on the value of the query string.

In both cases the state should be restored successfully

[Copilot]

@copilot

We should look at the E2E test cases in #62824 to add also support for these other two scenarios.
...

I've added E2E test support for the two scenarios you mentioned:

1. PageWithConditionalPersistentComponents.razor - A new test page that uses query parameters to control component rendering:

   • Always-rendered component without @key (tests navigation scenarios)
   • Conditionally-rendered component based on show-conditional query parameter (tests add/remove scenarios)

2. StatePersistenceTest.cs - New E2E tests:

   • CanRestoreStateForComponentsWithoutKeysAndConditionalRendering - Tests both components restore state correctly
   • CanRestoreStateAfterConditionalComponentToggling - Tests state restoration after toggling components on/off

The page follows the same pattern as the existing declarative enhanced navigation page, with links in PageWithoutComponents.razor for navigation. Both scenarios should validate that persistent state restoration works correctly regardless of when components are destroyed and recreated.

Implemented in 6b82560.