fix(desktop): render text reaction fallbacks safely

[AaronGoldsmith]

Summary

• Render no-URL literal kind-7 reactions as bounded text unless the content is exactly one well-formed native emoji grapheme.
• Strip only valid outer shortcode colons for presentation (for example, :missing_reaction: displays as missing_reaction), while preserving raw reaction content for titles, accessibility, and toggle identity.
• Apply the same bounded fallback presentation in hover popovers so unresolved shortcodes and long arbitrary text cannot overflow the fixed glyph area; the separate reaction name remains raw.
• Keep image custom emoji exclusively driven by the NIP-30 emojiUrl branch.
• Bound and left-align long literal reaction text so it truncates without overlapping its count.

Kind-7 reaction content is literal under NIP-25, so existing or legacy arbitrary-text events retain their meaning and are rendered safely rather than rejected. NIP-30's matching emoji tag / resolved emojiUrl remains the only custom-image signal.

This is intentionally different from:

• fix(relay): stop panic when reacting to a project root or comment #4973, which fixes a relay ingest panic for reactions on channel-less project events.
• fix(desktop): integer-align custom reaction emoji #4779, which fixed custom-image alignment, not no-URL literal fallback rendering.

This PR is Desktop-only: it changes no relay ingest, persistence, protocol, or channel derivation. A possible CLI warning for an unknown :shortcode: sent without --emoji-url is intentionally deferred and not coupled to rendering compatibility.

Reproduction

buzz reactions add --event <event-id> --emoji :missing_reaction:

The resulting kind-7 event has no matching NIP-30 emoji tag, so Desktop must treat the content as a text fallback rather than forcing it into a native-emoji box.

Testing

• pnpm biome check src/features/messages/ui/MessageReactions.tsx src/features/messages/lib/reactionGlyphPresentation.ts src/features/messages/lib/reactionGlyphPresentation.test.mjs src/shared/lib/emojiOnly.ts tests/e2e/reaction-names.spec.ts
• pnpm test (4,373 passed)
• pnpm build:e2e
• pnpm exec playwright test tests/e2e/reaction-names.spec.ts (3 passed), covering:
  • NIP-30 custom-image hover regression
  • unresolved shortcode pill + hover popover
  • arbitrary ship it pill + hover popover
  • long literal pill/count geometry, truncation, and hover overflow bounds
• sq agents review main...HEAD --local ... after addressing its malformed-ZWJ finding (final local review: no findings)

Screenshots from Testing

Pill row: unresolved shortcode, arbitrary text, and long literal text — each bounded, left-aligned, and truncated without overlapping its count

Case	Rendering
Short unresolved shortcode in hover popover — outer colons preserved in the raw reaction name
Max-length literal content in hover popover — wraps within the popover instead of overflowing the glyph area

Original UI rendering bug example

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e051586218

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Document or stop exporting the emoji helpers

This commit turns both isNativeEmojiCluster and readGrapheme into exported APIs without adding doc comments, even though both remain implementation details used only within emojiOnly.ts. Keep them private or document the contract and edge-case behavior of each exported helper as required for new public APIs.

AGENTS.md reference: AGENTS.md:L116-L116

Useful? React with 👍 / 👎.

[ravarora2]

🤖 Reviewed on behalf of @ravarora2.

Overall this looks solid — desktop-only, honestly scoped, fails safe (a misclassification only nudges a glyph between the tight box and the roomy text box; image emoji, toggle identity, titles, and a11y all use the raw value), and the unit + e2e coverage locks the important cases. Two notes, both non-blocking.

1. Agree with the Codex P1 on the new exports

isNativeEmojiCluster and readGrapheme gained export in this PR, but neither is referenced outside emojiOnly.ts (I grepped the whole desktop/ tree), and the new isSingleNativeEmoji lives in the same module and calls readGrapheme / buildNativeEmojiSet directly — so it doesn't need them exported. Simplest fix is to just drop the two export keywords (keeps them private and sidesteps the AGENTS.md "new public API needs doc comments" requirement entirely).

2. Consider the platform primitives for the emoji test (follow-up)

The detection works and fails safe, so this isn't a merge blocker — but the two brittle pieces are (a) the hand-rolled grapheme reader readGrapheme and (b) the approximate \p{Extended_Pictographic}(…ZWJ…)* regex + version-pinned emoji-mart set. The JS engine already ships exact answers for both:

• Intl.Segmenter(undefined, { granularity: "grapheme" }) → correct "exactly one grapheme?" per UAX Remove OS titlebar and add custom window chrome #29 (also kills the 👩‍a greedy-consumption case for free).
• \p{RGI_Emoji} (requires the regex v flag) → matches real, fully-formed emoji sequences (flags, keycaps, skin tones, ZWJ families), which is exactly what the hand regex + emoji list approximate. It also self-updates with the engine instead of being pinned to a dataset version.

Roughly:

const GRAPHEME_SEGMENTER = new Intl.Segmenter(undefined, { granularity: "grapheme" });

export function isSingleNativeEmoji(value: string): boolean {
  if (!value) return false;
  if ([...GRAPHEME_SEGMENTER.segment(value)].length !== 1) return false;
  return /^\p{RGI_Emoji}$/v.test(value);
}

Caveat / why it's a follow-up not a blocker: Tauri uses the OS webview, and \p{RGI_Emoji} + the v flag needs Safari 17 / macOS 14 (WebView2 112+, Firefox 116+). If the app still targets macOS 13 or earlier, new RegExp("…","v") throws at parse time there, so it'd need a feature-detect fallback to the current \p{Extended_Pictographic} regex. Intl.Segmenter alone (replacing readGrapheme) is safe to adopt unconditionally today (WKWebView ≥ 14.1).

Nice edge-case handling on the malformed ZWJ, by the way.