[loganj]

Summary

The Join a community dialog now works with Back and Forward, like Settings and the other dialogs that follow the app's navigation history rules (docs/navigation-history.md). Before, it lived outside navigation: Back left the view under the dialog while the dialog stayed open, and Forward could not bring it back. This is the follow-up promised in #2991.

It applies to every way the dialog opens:

• an invite link (buzz://join, the relay's invite page, Open in Buzz),
• the community picker's Join a community,
• Settings → Builderlab → Create community (opened on the new community, from Join a community right after creating it in Settings #2991).

Action	Result
Back	Closes the dialog. The view under it (page, conversation or Settings section) stays as it was.
Forward	Reopens the dialog as it was left: address, invite code and edited profile. It does not connect, claim an invite or publish a profile by itself; the person chooses Continue.
Close / Escape	Closes the dialog. Back and Forward do not bring it back. Closing the view under it (for example Settings) also retires it.
Finishing the join	Opens the new community. Back returns to the view under the dialog, not to the dialog or to an older dialog for the same community.
Back while the dialog is admitting or publishing	Stays on the dialog, as its Close button is disabled during those writes.
Reload	Shows the link's address again for the same account only, without a code or typed text.

Invite codes never go into history, the URL or session storage. They stay in memory for one opening of the dialog: two invites to the same community keep their own codes, and editing the address clears the code, so it never returns beside another address. After a reload an invite link must be opened again to use its code.

Details

• The dialog is a join: { viewer, visit, community? } presentation on the visit beneath it, in the same way Settings presents over a page: the page underneath keeps its visit and stays mounted. Pages and their target comparisons see the target without join. visit is an opaque token for one opening.
• The dialog reports its form (address, code, and the profile once edited, tagged with its community) to one in-memory record per opening, with the "connect at once" instruction (used for a community just created). A restored profile applies only to the community it was edited for. "Connect at once" is used once; Forward and later presentations wait for Continue. A change of account discards the other account's codes.
• Finishing a join replaces the dialog's visit with the joined community's page, then retires this opening and every other opening that now offers the community actually joined (its edited address, else its original).
• Back is held on the dialog while it admits (including a signed-in account's admission straight from the address step) or publishes, as its Close is. Settings beneath the dialog cannot be dismissed then either.
• Under the dialog, Settings keeps its section, scope, provider and plugin details, but not a card's one-shot route (such as Create community) or a plugin import. When a join opens over a visit with such data, the navigation controller first resolves that visit to the view the join keeps (as it does for the channel beneath a Members handoff). Reload, Back and Close then return to Settings and never replay the action it came from.
• A join restored together with Settings opens only after Settings has taken focus. Settings waits for the launch screen, and if the join opened first, Settings covered it and each dialog hid the other from the keyboard and assistive technology.
• Browser coverage: hosted-create-join.spec.mjs now also reloads at the join (Join restores over Settings with no Create form, and Back shows the card's overview, not Create; both failed before the fix). It then holds a profile publication, tries Back and Escape, and refuses the publication; the join, its draft and Settings survive.
• Two openings intentionally create no visit: first run's landing screen (there is no view under it), and the picker's Join a community while a failed link is waiting for Retry (a new visit would replace that failure and its Retry).
• Also corrects a stale line in docs/plugin-architecture.md: after creating a hosted community, the Builderlab card opens the join dialog (it copies the address only when no identity is ready to join with).

Video

The picker's Join a community in the browser build (Chromium, slowed down): type an address, Back closes the dialog over the same view, Forward reopens it with the typed address, Reload shows the dialog again without the typed text, Close retires it (Forward is disabled).

join-dialog-history.mp4

🤖 Generated with Claude Code

[wesbillman]

🤖 Star Lord’s automated source-review follow-up via Wes’s account, with independent Rocket, Mantis and Groot review.

Reviewed head 8c7b94e3954d0abf40bc56b402397419580fb090 against base 9cc2881d63bd8d28fddf56065fc36d8dcbc7741e, focusing on the repair since 219fc6fe.

The prior P2, “preserve Members beneath Join,” is resolved in source. The new !target.join condition skips both Members handoff branches, so opening Join preserves the original Members visit. The added warm/cold controller tests exercise navigation.open and assert that Back returns to that exact entry, then to the preceding conversation or home. No new actionable findings in this bounded follow-up; no changes requested.

The original feature patch and base are unchanged, so earlier account/invite/admission coverage is retained. Back/Forward, explicit dismissal and replacement paths were traced in source. No tests, builds or apps were run; the new tests do not directly exercise Forward, Close or rendered focus, and browser/native behavior remains unverified. This is a COMMENT review, not approval.

[wesbillman]

🤖 Star Lord automated source review via Wes’s account, integrating independent Rocket, Mantis and Groot reviews.

Reviewed 9723171e6647359332f3442b9ca5362481b935c0 against base/merge-base 58116b826171d190a7376fc57b0509c32c507dde. No new actionable findings in this bounded follow-up; no changes requested. The prior Members-under-Join repair remains intact.

The new matcher uses the same pasted-address parser and canonical community URL conversion as dialog submission. This allows completion to retire same-viewer sibling openings edited to a bare host or invite URL for the joined community. Edited empty or invalid destinations do not fall back to their original address; retirement reads the form before deleting its in-memory state. The rebased admission path retains its write guard and passes the newly parsed invite code into that submission.

Validation was source-only: no tests, builds or apps were run. The added helper assertions cover bare-host and invite-URL matching, not full sibling-visit retirement or browser/native/focus behavior. A one-time CI snapshot showed 34 successes, 23 running checks, one skip and a failed Rust and tool integration job; available annotations reported exit code 1 without establishing the cause. This review does not establish passing CI or runtime behavior.

COMMENT review only, not approval.

[wesbillman]

🤖 Star Lord automated source review via Wes’s account, integrating independent Rocket, Mantis and Groot reviews.

Reviewed 70e1f3460adcd4396f1b4470e266405861dd442e against base/merge-base 3a1eb5601e997811009d01601786df8af9393a7f. No new actionable findings in this bounded follow-up; no changes requested. Prior Members and address-matching fixes remain covered.

The new subscription releases an opening’s in-memory state when its last tracked navigation visit leaves the retained history window, while preserving it for passive Back/Forward. Completion evaluates sibling destinations before dismissal publishes cleanup. Pasted invite submission now normalizes the address and keeps its code in the editable code field, so a later Continue cannot restore the link’s original code over an edited or cleared value.

Source-only validation: no tests, builds or apps were run. The added mounted-app assertions cover Settings-close cleanup, branch cleanup after Back, and edited/cleared pasted-code restoration. Capacity eviction, multiple visits sharing a token, lookup-error recovery, browser/native behavior and runtime focus were traced or remain unexercised; the assertions do not establish those workflows. A one-time CI snapshot had 40 successes, 18 running checks and one skip, with no failures at that moment; CI completion was not established.

COMMENT review only, not approval.