Files
buzz/mobile/test/features/onboarding
Matt Toohey 46cdc52d23 test(mobile): lock in invite-page and bare-host community link entry (#9047)
Both mobile community-link fields (Add community and the
welcome/onboarding "Enter a community link" page) already accept a typed
or pasted `https://<host>/invite/<code>` link and keep the code. They
also read a bare host as `wss://`. This PR adds regression coverage for
both. **It doesn't change any production code.**

Companion: block/buzz-app#2412 fixes the same two inputs in buzz-app's
Join a community.

## What's covered

- **`community_link_input_test.dart`**
- The address loop is now an input → relay table, with two new rows:
`secondary.example` and `relay.example.com:8443` (the port is kept).
- The invite case now uses `https://primary.example/invite/fixture`, and
expects relay `wss://primary.example` with code `fixture`.
- Two new rejected inputs: `ws://secondary.example`, and the invite path
with a trailing slash, which the relay doesn't serve.
- **`onboarding_entry_routes_test.dart`**: before the bare-host step,
the journey pastes the invite link into the Add route's field. It
expects the app-level `InviteJoinSheet` to show host `primary.example`
and code `fixture`.

## Shown to catch a regression

I removed the invite/add-community short-circuit in
`parseCommunityLinkInput`. Both the invite unit case and the new journey
step then failed.

## Not in this PR

Two parser differences are left for a separate decision, along with the
tests that depend on them:
- `buzz://connect?relay=…`: mobile rejects it in the fields and silently
drops it as an OS link, but buzz-app, desktop and the web repo browser's
Connect button all use it.
- An invite-page link with a query string: mobile accepts it and throws
the query away, but buzz-app rejects it.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Signed-off-by: Matt Toohey <contact@matttoohey.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-06 09:49:51 +11:00
..