fix(composer): expand pasted text from chip label

[Iflaqbhat]

Fixes #1843

Summary

• Makes the pasted-text chip itself clickable, not only the small arrow icon
• Keeps the existing expand affordance while allowing users to click the Pasted · n lines label
• Adds keyboard support so focused pasted-text chips expand with Enter or Space

Verification

• Verified locally by pasting multi-line text into the composer and clicking the pasted-text label to expand it
• git diff --check
• pnpm --filter @openwork/app typecheck
• pnpm --filter @openwork/app test

Screen.Recording.2026-06-17.at.12.04.24.PM.mov

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	Jun 17, 2026 6:36am

[vercel]

@Iflaqbhat is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

No issues found across 1 file

_{Re-trigger cubic}

[Pablosinyores]

The refactor to pastedTextExpandLabelFromTarget and moving the affordance onto the whole chip reads well — icon aria-hidden with the label on the role="button" host is the right a11y shape.

Two things in the editor context:

• The chip now has tabIndex={0} inside the Lexical contentEditable. Does Tab now stop on every pasted-text chip while navigating the composer? In a draft with several pastes that could get noisy / pull focus out of the typing flow — worth checking how it feels.
• For role="button", Space normally activates on keyup (keydown just prevents scroll). Handling both on keydown with preventDefault stops the scroll so it's fine in practice — just flagging for strict button semantics.

Click/keyboard expand path otherwise looks consistent.

[Iflaqbhat]

@Pablosinyores Thanks, that makes sense.

For tabIndex={0}, I kept the chip keyboard-focusable because the whole chip is now the interactive expand control. Removing it would make the chip nicer for Tab flow, but worse for keyboard accessibility because mouse users could expand it while keyboard users could not.

The Space key point is fair. Since we prevent default scrolling, the current keydown behavior works in practice, but I agree it is slightly different from native button semantics. I can adjust Space to activate on keyup if maintainers prefer that.

I’ll do one more local keyboard pass with multiple pasted chips and can tweak if the Tab flow feels too noisy.

[Abhijeet1005]

Pulled this on Windows and traced through it — clean a11y/UX fix, looks correct.

What I checked

• The refactor makes the whole chip one interactive control (role="button", tabIndex=0, aria-label, focus-visible ring) and turns the old inner <button> into an aria-hidden decorative icon. Good call — one clear keyboard target, no nested-interactive element.
• The thing I most wanted to confirm: a new capture-phase key handler in the composer is exactly where you'd risk breaking Enter-to-send. It doesn't — handlePastedTextExpandKeyDown only acts when event.target is inside [data-pasted-expand-label] (a focused chip). While typing, the target is the contentEditable root, so it returns early without preventDefault, and Enter-to-send / Shift+Enter / spaces are untouched. Only a Tab-focused chip responds to Enter/Space — which is the intent. Same scoping holds for the click/mousedown capture handlers.
• pnpm --filter @openwork/app typecheck -> clean.

I couldn't exercise the click/focus behavior live (that needs the full app running), so this is a static + typecheck pass — but the logic is sound and matches the recording. LGTM.

[Iflaqbhat]

@Abhijeet1005 Thanks for the feedback and for checking this on Windows!