[iiamlewis]

Resolves #5773

Stacked on #5774 (the Progression tab), which is stacked on #5734. The base is that PR's branch, so this diff shows only this change. Part of #5760.

Description:

openfront.io/player/<publicId> now opens that player's profile directly, so a shared link lands on a real page. The backend's link previews make the same URL unfurl in Discord, X and WhatsApp with the player's level and card.

Opening from a link (ModalRouter.ts, Main.ts)

• ModalRouter gains registerPath() and routeFromPath(); Main.handleUrl tries the path just before the hash.
• Accepted: /player/<id>, with or without a trailing slash, behind /w<n>/ and /v/<commit>/, with an optional ?tab=stats|games|clans|progression.
  • Ids must match [A-Za-z0-9_-]{1,22}; anything else is ignored. The hash form (#modal=profile&publicID=…) still works.
• While open from a path, the URL keeps the path and tab changes are written to ?tab=.
• Closing (Back or Escape) goes home and replaces the URL with / (or /v/<pin>/ on a version-pinned page), so a reload doesn't reopen it. Opening another popup in-app hands the URL back to the hash form.

Links (utilities/PlayerProfileUrl.ts)

• playerProfileUrl() is now shareOrigin()/player/<id>: the page's own origin on the web, and the site origin in the desktop shell, the same as lobby invite links.
• Callers: the profile header chip, the account "Share Profile" button, and the nav account menu's copy action.
• The friends box also accepts a pasted /player/<id> link.

Share row (components/ProfileShare.ts)

Under the profile card:

• Copy link: copies the canonical URL, shows the app's "Copied!" toast, and announces it through an sr-only aria-live status, since the toast isn't a live region.
• Share on X: opens https://x.com/intent/post?url=…&text=… with noopener,noreferrer. The desktop shell already sends https links to the system browser.
• Copy for Discord: "Check out {name}'s profile on OpenFront", then the link on the next line, so it pastes as a ready message; Discord unfurls the link.
• On touch devices with navigator.share: one Share button opens the native share sheet instead of the three. It's gated on touch because desktop Chrome on Windows also exposes navigator.share. A dismissed sheet does nothing; any other failure falls back to copying the link.

"Player not found"

Replaces the old 📊 line with the approved design:

• a person-with-question-mark icon in a circle;
• "Player not found" and "We couldn't find a player at this link. It may be mistyped, or the account may have been deleted.";
• the opened link, shown faintly, only when opened from a path;
• Play OpenFront (home) and View leaderboard (closes the profile and opens the leaderboard): side by side from sm up, stacked on a phone.

The old player_profile.not_found key is removed; the translation test fails on unused keys.

Server (src/server/PlayerProfileRoute.ts)

• The master's SPA fallback already serves the app shell at a bare /player/<id>.
• /w<n>/player/<id> reaches a worker, which returned 404, so registerPlayerProfileRoute serves the shell there, in the GamePreviewRoute style.
• The dev proxy bypass covers /w<n>/player/ as well as /w<n>/game/.

Not in this PR

The "Show my profile in search engines" setting needs a backend flag and the site Worker's noindex. A code comment in renderProfile marks where it will connect.

Screenshots

From this branch at 2x, opened from real /player/<id> links. The profile is sample data given to the popup, because the dev API has no such player. The not-found shots are the real failure path.

Desktop: the profile card and the share row. Signed-in and signed-out viewers see the same page (the "New to OpenFront?" banner was removed in a18d74e).

Desktop, Progression (from #5774), opened with ?tab=progression:

Player not found (the real failure path, from /player/aB3dE5fX):

Phone: Stats (the three share buttons collapse to a native Share button on touch devices with share support; headless Chrome has none, so the three show here), Progression, and Player not found with the buttons stacked.

Added: sharing level-up moments

Players can now share a milestone, Legend or a new prestige rank, using the same Copy link / Share on X / Copy for Discord options as the profile. The link is the profile with the moment, e.g. /player/wonder01?moment=level50. openfrontio/infra#910 unfurls it as that moment's celebration card.

• End-of-game popup:

  • A "Share Level 50" or "Share Legend" button sits in the footer, between Exit Game and Keep playing.
  • It opens the three options as a menu above it. On a touch device with a share sheet, it opens the share sheet directly.
  • On phones it takes its own full-width row above the other two buttons.

• When it shows:

  • only for the server's confirmed result, never the early estimate shown when a player is eliminated;
  • only once the reveal has finished or been skipped;
  • only for a signed-in player with a public ID;
  • only when the game reached a milestone (10, 25, 50, 75 or 100) or made the player a Legend.

  With several milestones in one game it shares the highest, and Legend wins over any level.

• Prestige ceremony: a share row with a dark backing sits between the title and Continue. Clicks on it don't close the ceremony.

• Code:

  • <profile-share> defines its actions once and gains a menu layout. The profile's own row works as before.
  • MomentShare.ts works out what to share.
  • GameXpPanel fires xp-reveal-settled when the reveal ends.
  • PrestigeFlow takes a publicId.

• New en.json keys: progression.share_moment_level, share_moment_legend, share_text_level, share_text_legend, prestige.share_text.

Screenshots from this branch at 2x. The XP results are sample data given to the popup. In dev the link starts with the local origin; in production it's https://openfront.io.

Level 50, closed and open, and Legend:

Phone, closed and open:

Prestige ceremony, desktop and phone:

Testing for these additions:

• MomentShare.test.ts, plus 7 menu tests in ProfileShare, 8 in WinModalXp and 3 in PrestigeFlow. They cover:
  • result-only, never for the early estimate;
  • hidden mid-reveal, signed out, or with no public ID;
  • the highest milestone chosen, and Legend over a level;
  • the link and text built correctly;
  • clicks on the ceremony's share row not closing it.
• All 3,528 client tests pass. tsc and lint are clean.

Added (2026-10-04): share ring on hover, and a share row on the Legend ceremony

• Share ring:
  • The flash: a quick yellow ring flashes around a share button when the mouse moves onto it, or on keyboard focus (:focus-visible). It's at full strength instantly, held for 80 ms, then fades over 320 ms while growing to 1.04×.
  • When it plays: once per hover; a hover while it's still playing is ignored. It's never shown on touch devices ((hover: hover) and (pointer: fine) only) or under reduced motion.
  • How it's drawn: ProfileShare renders its own ring element and plays it with ring.animate(...). It's not a pseudo-element on the trigger, because the trigger's .win-action::after is already its hover streak.
  • Where it appears: the end-of-game footer button, the prestige ceremony's row and the profile page's row. The share buttons no longer rise in; they're simply there.
• The Legend ceremony (from Add profile cards and the prestige flow #5734) now has the share row between "The top of the track…" and Continue, linking ?moment=legend the same way the prestige ceremony does.
  • It stops clicks from reaching the ceremony, and doesn't show without a public ID.
  • Tab now cycles through the share buttons and Continue inside the ceremony, with Continue still focused first.
• Merges: this also merges Player profile: Progression tab, reward track, profile links and sharing, and end-of-game rewards #5774's reward track (17a3aa555) and Add profile cards and the prestige flow #5734's latest (c6383aeb6).

Built UI, sample data:

The share button in the end-of-game footer, hovered twice:

P6-share-ring-footer-hover.mp4

The Legend ceremony's final screen with the share row:

Tests:

• ProfileShare.test.ts: the ring element, one animate per hover with the exact keyframes, a hover during playback ignored, focus-visible, touch and pen ignored, nothing under reduced motion or a coarse pointer.
• LegendCeremony.test.ts: the row only at the end, between the line and Continue; URL and text; clicks kept; no row without an ID; Tab cycling.
• WinModalXp.test.ts: the ?moment=legend URL.

Results: tsc and lint are clean, and tests/client passes (3,654).

Testing

• New:
  • PlayerProfilePage.test.ts: path parsing in every form, invalid ids ignored, opening on load, ?tab= sync, closing resets the URL, the not-found state;
  • PlayerProfileUrl.test.ts;
  • ProfileShare.test.ts: copy calls the clipboard, X URL encoding, the native share path and its fallback;
  • tests/server/PlayerProfileRoute.test.ts.
• Updated: ShareBase, NavAccountMenu, FriendsListPublicIdInput, and the profile tests' mocks.
• Results: 63 tests pass in the 8 targeted files, plus the translation tests. tsc and npm run lint are clean. In the full suite the only failures were the known InventoryModal / MainInitialize timeouts, which pass on their own.

Please complete the following:

• I have added screenshots for all UI updates
• I process any text displayed to the user through translateText() and I've added it to the en.json file
• I have added relevant tests to the test directory

Please put your Discord username so you can be contacted if a bug or regression is found:

Iamlewis

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (1)

• v\d.*

---

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: f0b1c471-d6a5-49b6-a5b3-a4f95cac1284

---

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

---

_{Comment @coderabbitai help to get the list of available commands.}

[Celant]

Coordinated review

Same batch, reviewed with the backend repo available locally. CI review was stale and has been re-run.

On the og:image v question I raised on the backend side: not applicable here, and the answer is good. This client never composes the card URL — it emits the page link (${ClientEnv.shareOrigin()}/player/<id> plus an optional ?moment=). The card URL is built by the backend's site worker, whose cardUrl() produces ?v=${progress.prestige}-${progress.level}, so profile links do unfurl with the 6-hour variant rather than the 5-minute one. The only og:image in this repo's src/ is the pre-existing game-preview route. Worth knowing the flip side: because the client has no hand in the card URL, it also has no lever on card freshness.

moment bounds match the server. gameShareMoment() yields only legend or a level drawn from MILESTONE_LEVELS (10/25/50/75/100, all inside the server's 2..100), and momentSlug() emits exactly legend/level<N>/prestige<N>, matching parseMoment's regex and bounds in both the API's card route and the site worker's copy. One soft spot below.

Input validation is clean: publicId from the URL is validated by PUBLIC_ID = /^[A-Za-z0-9_-]{1,22}$/ before any use — matching the API's own regex — and every outbound use re-encodes it. ProfileShare sends nothing but a constructed intent URL to window.open(..., "noopener,noreferrer"). I chased the share menu's capture-phase outside-click handler as a possible shadow-DOM retargeting hazard; it isn't one, because WinModal, BaseModal, LegendCeremony, PrestigeFlow and ProfileShare all override createRenderRoot() to render into light DOM.

Two intended semantics worth being aware of, both confirmed against backend comments: the server draws a level<N> moment only within the player's current run, so a shared level50 link reverts to the plain card once that player prestiges ("the card never claims what isn't so"); and the in-app view ignores ?moment= entirely, so a recipient clicking through sees the plain profile while the unfurl celebrated the moment.

3 finding(s): 3 low

---

Findings whose anchor falls outside the diff:

[low] The prestige share slug uses the server's raw rank, unclamped

src/client/components/PrestigeFlow.ts

renderShare(rank) is reached with rank = this.outcome?.progress.prestige ?? this.nextRank(before), and momentShareUrl → momentSlug interpolates it straight into prestige${moment.rank}. Every other consumer of that number goes through clampPrestige() or nextRank(); this one takes PrestigeResponse.progress.prestige as a bare z.number().

Failure scenario: a 0, an 11, or a non-integer yields prestige0/prestige11/prestige1.5, all of which the card route answers with badRequest({ resource: "moment" }) — so the shared link unfurls with no image at all, on the single most celebratory surface in the feature. Only reachable if the server returns a rank outside 1..10, which it doesn't today.

Suggested fix: clampPrestige(rank) before building the slug, and/or have momentSlug return null for an out-of-range value so the share row drops rather than emitting a 400.

Worth a table test over {level: 1, 2, 100, 101} and {prestige: 0, 1, 10, 11} asserting the slug is either refused or inside the range the card route accepts — nothing currently pins that seam.

[low] The address bar and the not-found panel's "link you opened" can name the wrong player

src/client/PlayerProfileModal.ts

BaseModal.open() returns before modalRouter.syncOpened() when wasOpen is true; PlayerProfileModal.onOpen() then snapshots `${window.location.host}${window.location.pathname}` into openedLink.

So re-opening the profile modal for a different publicID while it's already open never calls syncOpened → never calls leavePath() → the URL keeps /player/<old-id>, isPathRouted("profile") stays true, and openedLink is captured from the stale path. syncTab then writes ?tab= onto the wrong player's path, and a reload opens the wrong profile.

Latent today — the only open()-while-open path is returnToGames(), which re-opens the same player. It becomes live the moment anything opens one profile from inside another (a clan roster, a friends-list entry rendered in the profile).

Suggested fix: derive openedLink from the id the modal is actually about rather than from window.location, and/or let syncOpened run for an already-open modal whose args changed.

[low] The dev-server rewrite only covers the worker-prefixed profile path

vite.config.ts

/^\/w\d+\/(?:game|player)\/[^/]+/ — but PROFILE_PATH and src/server/PlayerProfileRoute.ts both accept a bare /player/<id>. Only the /w<n>/ form gets the dev bypass, so npm run dev plus a plain profile link relies on Vite's SPA fallback instead.

Suggested fix: cosmetic — match the two regexes so dev behaves like production.

[iiamlewis]

Folded into #5774, which now carries the Progression tab, this PR's profile links and sharing, and #5786's end-of-game rewards as one PR (GitHub shows this one as merged because its commits are now in #5774's branch). Nothing from this PR was dropped; review continues on #5774.

🤖 Generated with Claude Code

[github-actions]

🤖 Claude Code Review

Skipped: this pull request is already merged (state MERGED), so no review was performed.