Blueprints: Fix intermittent blank workspace when creating documents from blueprints (closes #21996)

[AndyButland]

Fixes #21996

Description

This PR addresses #21996 which I haven't been able to replicate until I was provided a database upgrade from 13 which I would intermittently see a problem when creating a new document from a blueprint. It was most easily replicated when you create one, but before saving create another from a different blueprint. You would end up with a blank, grey workspace and a TypeError: t.provideAt is not a function error in the console.

The provided database had quite a lot of blueprints and they were all fairly complex with block layouts, so the suspicion is a race condition. With many complex blueprints the scaffold payload is larger and the server response slower, widening the window enough for the inner router's history.replaceState redirect to fire during the outer navigation's await.

The problem looks to be solved with the following fix.

1. Blueprint creation left the previous workspace active during an async fetch — The create() method only called resetState() / loading.addState() inside createScaffold(), which runs after the blueprint data is fetched from the server. During that async gap, the previous document-workspace-editor (still mounted in the DOM) remained fully rendered. Its inner router slot processed a requestAnimationFrame notification from the original history.pushState and resolved the default-variant redirect route, which called history.replaceState. That global history event triggered the outer router slot's navigation-cancellation listener, silently aborting the navigation—the new editor element was never appended to the DOM.

Further Defensive Fixes (now removed)

In working on this I found and applied two other resolutions to issues, that didn't turn out to be the core solution to the problem. They are now removed, to keep the PR as simple as possible and to reduce any risk of regression in other areas. Nonetheless, they may be worth considering and picking up in another PR if considered worthwhile:

2. Router slot route comparison only checked paths — UmbRouterSlotElement.routes setter compared routes solely by their path strings. When workspace view contexts were destroyed and recreated (same paths, new instances), the setter skipped forwarding the updated routes to the native router slot. Stale route setup callbacks—still closing over the destroyed view contexts—remained active.

3. UmbViewController.destroy() caused a hard TypeError — The destroy method used (this as any).provideAt = undefined to shadow the prototype method. When a stale route callback invoked provideAt on a destroyed context, this produced an unrecoverable TypeError instead of a graceful no-op. Replaced with a proper #destroyed flag that guards provideAt().

As noted, these are now not part of this PR, but can be seen in the first two commits.

Testing

May be tricky to reproduce unless you want a copy of the database that shows the error, but it should be enough to verify that new documents can be created when selected from a list of blueprints, and you can successfully create one, scaffold it, then change your mind and create again from a different blueprint.

[claude]

PR Review

Target: origin/main · Based on commit: 858a49b92df2ddb4eebcd80d86e0b53f72cd748c · Skipped: 0 noise files out of 3 total

Fixes a three-part race condition causing a blank workspace / TypeError: t.provideAt is not a function when creating documents from blueprints on upgraded databases. Each changed file addresses one root cause.

• Other changes: Blueprint creation now shows a loading indicator immediately (before the scaffold fetch), preventing the previous editor's inner router from firing history.replaceState during the async gap — observable behaviour change for the blueprint creation flow.

---

Suggestions

• document-workspace.context.ts:259: The blueprint-fetch loading state is implicitly cleared when createScaffold() calls this.resetState() → this.loading.clear(). This is verified correct, but making it explicit (this.loading.removeState('blueprint-fetch') immediately before the createScaffold() call) would make the add/remove lifecycle self-contained in create() and not reliant on base class behaviour.

---

Approved with Suggestions for improvement

Good to go, but please carefully consider the importance of the suggestions.

The three targeted changes correctly address each layer of the race condition: reference-based route comparison catches changed setup callbacks even with identical paths, the #destroyed guard on provideAt() replaces an unsafe prototype-property shadow with a proper state flag, and the early resetState() + loading state in the blueprint branch closes the async window that allowed the inner router to cancel the outer navigation. The PR description's root-cause analysis is thorough and the fix is minimal and precise. Well done!

[Copilot]

Pull request overview

Fixes a timing-dependent blank workspace issue when creating documents from blueprints on upgraded databases by hardening routing, view-context teardown behavior, and the blueprint creation flow.

Changes:

• Update umb-router-slot to detect route changes by route object identity (not just path strings) so refreshed route instances correctly replace stale setup callbacks.
• Make UmbViewController.provideAt() a safe no-op after destroy via a #destroyed guard instead of shadowing the method on the instance.
• Put the document workspace into a loading state immediately when creating from a blueprint (before the async scaffold fetch) to prevent the previous editor/router from interfering with navigation.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/Umbraco.Web.UI.Client/src/packages/documents/documents/workspace/document-workspace.context.ts	Forces immediate reset/loading during blueprint creation to close the race window that could cancel navigation.
src/Umbraco.Web.UI.Client/src/packages/core/view/context/view.controller.ts	Prevents stale callbacks from throwing by guarding provideAt() after destruction.
src/Umbraco.Web.UI.Client/src/packages/core/router/route/router-slot.element.ts	Ensures updated route instances are forwarded to the underlying router slot even when paths are unchanged.