Application Customizers with DynamicDataProvider incorrectly registered when switching sites

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

Client Environment

• Browser: Microsoft Edge 140.0.3485.94
• SPFx Version: 1.21.1
• Node.js Version: 22.20.0

SharePoint Online Setup

• Application Customizers: 3 deployed globally (not added to all sites)

  • Repository: mobun/spfx-tests

• Global Tenant-Wide Extension List:

  • Add item for:
    • app_customizer_1
      
    • app_customizer_2
      

• Site Collections:

  • SC1: All 3 solutions enabled
  • SC2: Only app_customizer_3 enabled

Describe the bug / error

When navigating between sites in SPO using an <a> tag link, the application customizers that use DynamicDataProvider are incorrectly registered on the destination site.
Additionally, these customizers are not activated for the new site.
You can see the issue in the console (where "app_customizer_3" is active).

Steps to reproduce

1. Open the first SiteCollection (SC1)
2. Reload the Page with Cache (F5) - Hard Reload (CTRL+F5) "fixes the issue"
3. Open the second Site Collection over a-tag
4. See in the console log that non deployed solutions (app_customizer_1 & app_customizer_2) are accessible over DynamicDataProvider (console.log of app_customizer_3)

Expected behavior

• When navigating between SharePoint Online sites via an <a> tag link:
  • Only the Application Customizers configured for the target site should be registered.
• Application Customizers that are not enabled for the current site must not be registered or loaded.
• The active configuration of the destination site should be fully respected.

A few weeks ago, the corresponding setup was still working, and in recent days we have observed tenants on which the error has already occurred and tenants on which the error has not yet occurred.