The job page has both a breadcrumb and a separate back link, and they disagree about where the page belongs.
+page.svelte:101 hard-codes the breadcrumb parent to Activity and ignores returnTo.
+page.svelte:106 adds a "← Back to …" link that defaults to Provisioning (provisioning-presentation.ts:116), which is also what the sidebar highlights.
docs/development/ui-patterns.md says detail pages use Breadcrumbs, whose parent link restores the validated returnTo URL, and "Do not add a duplicate Back link."
Screenshots
From the synthetic UI preview. Progress records and a launch recipe were added to the disposable fixture database using the labels the worker records. "After" images are mockups made in an uncommitted copy.
Before:
After (mockup):
Fix
Take the breadcrumb parent from returnTo, falling back to Provisioning
Remove the separate Back link
The job page has both a breadcrumb and a separate back link, and they disagree about where the page belongs.
- `+page.svelte:101` hard-codes the breadcrumb parent to Activity and ignores `returnTo`.
- `+page.svelte:106` adds a "← Back to …" link that defaults to Provisioning (`provisioning-presentation.ts:116`), which is also what the sidebar highlights.
`docs/development/ui-patterns.md` says detail pages use `Breadcrumbs`, whose parent link restores the validated `returnTo` URL, and "Do not add a duplicate Back link."
**Screenshots**
_From the synthetic UI preview. Progress records and a launch recipe were added to the disposable fixture database using the labels the worker records. "After" images are mockups made in an uncommitted copy._
Before:
After (mockup):
**Fix**
- [x] Take the breadcrumb parent from `returnTo`, falling back to Provisioning
- [x] Remove the separate Back link
Reviewed c443ffa0dc. Both fix items are done, so I'm closing this.
Checklist
Breadcrumb parent from returnTo. The breadcrumb's parent is now Provisioning (+page.svelte:99). Breadcrumbs replaces it with the validated returnTo URL when there is one (Breadcrumbs.svelte:21-22), so Provisioning is the fallback, as asked.
Back link removed. The separate "← Back to …" link and its return logic are gone (+page.svelte:114).
Review notes
In the synthetic preview the header reads "Activity › Provisioning › Operation", with no separate Back link. Collection launch pages already pass returnTo (launches/[id]/+page.svelte:142,172), so they still lead back to the launch.
The full test suite passes locally (205 files, 2,591 tests), and npm run check reports 0 errors.
Minor and non-blocking: when there was no returnTo, the old Back link used the operation's single source. Links that don't pass returnTo, such as autoscaling's "View job" (PolicyCard.svelte:98), now lead back to Provisioning instead of the policy. Wrapping them in contextHref would restore that.
Reviewed c443ffa0dcf4db46d5c98729e3f3007e609e4753. Both fix items are done, so I'm closing this.
**Checklist**
- [x] **Breadcrumb parent from `returnTo`.** The breadcrumb's parent is now Provisioning (`+page.svelte:99`). `Breadcrumbs` replaces it with the validated `returnTo` URL when there is one (`Breadcrumbs.svelte:21-22`), so Provisioning is the fallback, as asked.
- [x] **Back link removed.** The separate "← Back to …" link and its return logic are gone (`+page.svelte:114`).
**Review notes**
- In the synthetic preview the header reads "Activity › Provisioning › Operation", with no separate Back link. Collection launch pages already pass `returnTo` (`launches/[id]/+page.svelte:142,172`), so they still lead back to the launch.
- The full test suite passes locally (205 files, 2,591 tests), and `npm run check` reports 0 errors.
- Minor and non-blocking: when there was no `returnTo`, the old Back link used the operation's single source. Links that don't pass `returnTo`, such as autoscaling's "View job" (`PolicyCard.svelte:98`), now lead back to Provisioning instead of the policy. Wrapping them in `contextHref` would restore that.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The job page has both a breadcrumb and a separate back link, and they disagree about where the page belongs.
+page.svelte:101hard-codes the breadcrumb parent to Activity and ignoresreturnTo.+page.svelte:106adds a "← Back to …" link that defaults to Provisioning (provisioning-presentation.ts:116), which is also what the sidebar highlights.docs/development/ui-patterns.mdsays detail pages useBreadcrumbs, whose parent link restores the validatedreturnToURL, and "Do not add a duplicate Back link."Screenshots
From the synthetic UI preview. Progress records and a launch recipe were added to the disposable fixture database using the labels the worker records. "After" images are mockups made in an uncommitted copy.
Before:
After (mockup):
Fix
returnTo, falling back to ProvisioningReviewed
c443ffa0dc. Both fix items are done, so I'm closing this.Checklist
returnTo. The breadcrumb's parent is now Provisioning (+page.svelte:99).Breadcrumbsreplaces it with the validatedreturnToURL when there is one (Breadcrumbs.svelte:21-22), so Provisioning is the fallback, as asked.+page.svelte:114).Review notes
returnTo(launches/[id]/+page.svelte:142,172), so they still lead back to the launch.npm run checkreports 0 errors.returnTo, the old Back link used the operation's single source. Links that don't passreturnTo, such as autoscaling's "View job" (PolicyCard.svelte:98), now lead back to Provisioning instead of the policy. Wrapping them incontextHrefwould restore that.