You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(web): PDF attachment chips no longer look like failed ones - #33805
ContextChip painted the label (filename and size) in the kind's accent via --context-chip-ink. The doc-pdf accent (oklch 0.62 0.16 24) resolves to almost the same red as --context-chip-invalid (errorForeground), so a healthy PDF chip looked like a failed one. Fix in ContextChip.tsx: the doc-pdf kind sets --context-chip-ink to currentColor and points --document-icon-stroke at the accent, so only the PDF icon stays red. The invalid state now sets --context-chip-ink to the accent itself, so invalid chips of any kind, PDFs included, still have red labels. Sent-message bubbles (TimelineUserMessageRow BUBBLE_CHIP_CLASS_NAME) used to override --context-chip-ink with --context-chip-message on the descendant chip, which the doc-pdf class would now beat. That override moves to a new --context-chip-message-ink variable that the base, doc-pdf and invalid ink and stroke values read first, so bubble behaviour is unchanged for every kind. Reproduced on main with a temporary browser test: the PDF chip label computed to the PDF accent. After the fix it computes to the surrounding colour while the icon stroke keeps the accent. Invalid PDF chips stay red; mention chips and bubbles with or without --context-chip-message behave as before. No new regex or parser. The scratch test was not committed: AGENTS.md says colour-only bugs are proven with before/after captures, not UI tests. No captures were taken in this step. The first push failed with a git.cafe credential lookup error (the global credential config sets usehttppath=true and the stored entry has no path); it succeeded with -c credential.https://git.cafe.usehttppath=false on that one command.
Commit bcee0f5 (origin/main). Fresh worktree, vp i, T3CODE_DEV_SEED=0 vp run dev (fresh empty database), paired a browser through the startup pairing URL, default light theme. On the new-thread composer I clicked 'Attach files' and uploaded a minimal valid one-page PDF (report.pdf, 193 bytes); the upload request returned 204. The composer chip 'File attachment, report.pdf, 1 KB' renders the PDF icon, the filename and the '1 KB' size all in red: computed colour of the label and size spans is rgb(179,55,57) (#b33739), while the text around it is near-black (oklch 0.21). On the same page --context-chip-doc-pdf resolves to #b33739 and --context-chip-invalid (the colour of a failed chip, from errorForeground) to #c10007, so a healthy PDF chip and a failed chip are nearly the same red. I did not send the message, so I did not check the sent-message bubble, and I did not check desktop or a custom theme.
Evidence
Evidence
On both fresh apps: create a new thread, type “Please review these attachments: ”, attach the same 193-byte report.pdf and notes.txt, then send using the free replay fixture. After completion, attach both files again in the composer and attach failed.pdf with its upload deliberately interrupted. Restore normal uploads, then capture the settled sent bubble and composer in each appearance below.
Every capture uses the real web dev app, Linux, headless Chrome 151.0.7922.108, a 1280×800 viewport, local direct connection, and fresh checkout-local databases started with T3CODE_DEV_SEED=0. Synthetic data only. Each still passed a byte-identical screenshot comparison at least 500 ms apart and uses the same automatic 1024×685 privacy crop. Custom light palette: canvas #f1f5f9, text #16324f, message surface #dce8f3, message foreground #17476b, error foreground #b00020.
Across these captures, healthy PDF filenames and sizes lose their red on head in both locations, while PDF icons retain their red cue. Invalid PDF chips remain red. The notes.txt control retains exactly the same colour on both commits. Default-light base PDF text is rgb(179,55,57), close to invalid rgb(193,0,7); head PDF text is neutral. Both sides completed four real attachment uploads with HTTP 204. This is static rendering evidence; no tests substitute for the images.
All six images were opened and inspected before upload. Downloaded uploads matched their local artifacts byte-for-byte. AI-assisted; verified with the tests and tools listed above.
Not shown:
Electron desktop and native mobile were not launched; this visual proof covers the web implementation.
Non-PDF coverage is the notes.txt generic file chip. Other ContextChip kinds were not individually exercised because they require separate context fixtures.
Custom-theme coverage uses one light palette. Opposite-lightness canvas/message bubbles, which activate a nonempty --context-chip-message override, and custom dark variants were not exercised.
Checks run
Temporary browser test (vp test run, chromium), not committed: failed on main (PDF label rgb(200,0,0), the accent, instead of the surrounding colour) and passed after the fix. It checked healthy and invalid PDF chips, a mention chip, and bubble chips with and without --context-chip-message. vp test run src/components/ContextChip.browser.test.tsx: pass. vp run check:changed: format, lint, knip 1/2 and 2/2, typecheck (2 packages), test (1 file), react compiler (2 files): all pass.
Not included
The PDF accent hue (oklch 0.62 0.16 24) is still close to errorForeground; the PDF icon stays red, which the issue allows.
The pr-closed accent (hue 16) is also near the error red and still colours its whole chip label; not part of this report.
The PDF accent is nearly the invalid-chip red, and context chips paint
their label in the accent, so a healthy PDF chip read as an error. PDF
chips now keep the red on the icon only and draw the label in the
surrounding text colour; invalid chips still paint the label red.
Message-bubble ink overrides move to a --context-chip-message-ink
variable so they keep winning over the per-kind ink.
Fixes#33044
AI-assisted; verified with the tests and tools listed above.
Macroscope's review found this PR approvable — PDF attachment labels adopt surrounding text color rather than looking like failures, while icons retain their accent. The change is limited to chip styling and message-bubble color inheritance.
No code changes detected at 232c908. Prior analysis still applies.
You can add or adjust custom eligibility rules. Learn more.
Reviewing files that changed from the base of the PR and between 9bba919 and 232c908.
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
No actionable comments were generated in the recent review.
Walkthrough
Context chips now derive their ink from message text instead of using the accent as the primary text color. PDF and invalid variants retain their respective accents as fallbacks.
Changes: Context chip ink colors
Layer / File(s)
Summary
Message ink and variant fallbacks apps/web/src/components/chat/TimelineUserMessageRow.tsx, apps/web/src/components/ContextChip.tsx
The user-message row supplies the chip message ink. The base, PDF, and invalid variants use message ink for chip text, with their existing accents retained as fallbacks. The PDF icon stroke also uses message ink with the PDF accent as fallback.
pingdotgg/t3code#25066: Introduced document-chip kinds and theme-derived accent and ink styling in the same component.
pingdotgg/t3code#13192: Moved context-chip rendering to the shared component changed here.
pingdotgg/t3code#25469: Added a chip kind that uses the generic ink fallback changed here.
Suggested labels:size:XS
Suggested reviewers:flamboh
Merge Risk: Minimal · previous review 9bba9
No material merge risk was identified for the PDF label color change.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title clearly describes the main change: healthy PDF attachment chips no longer look like failed chips.
Linked Issues check
Issue #33044 requires healthy PDF attachment labels and sizes to avoid error-like red while allowing a PDF cue. ContextChip.tsx gives healthy doc-pdf chips surrounding text color and keeps the acc…
Out of Scope Changes check
The changes are limited to context-chip color handling and the sent-message bubble override. Both changes directly support issue #33044; no unrelated changes are shown in the whole-PR diff.
Description check
The description covers the problem, implementation, linked issue, scope, reproduction, and verification. It includes before-and-after screenshots and focused test results. It does not identify the AI …
Full details: Linked Issues check
Explanation
Issue #33044 requires healthy PDF attachment labels and sizes to avoid error-like red while allowing a PDF cue. ContextChip.tsx gives healthy doc-pdf chips surrounding text color and keeps the accent on the document icon. The invalid state retains accent-colored text. TimelineUserMessageRow.tsx preserves the message-ink override for bubble chips.
Full details: Description check
Explanation
The description covers the problem, implementation, linked issue, scope, reproduction, and verification. It includes before-and-after screenshots and focused test results. It does not identify the AI model and harness, and it contains a conflicting statement that no captures were taken despite the listed captures; these are minor documentation gaps.
Finishing Touches
Generate docstrings
Commit to this branch
Create a new PR
Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Steps on both commits: create the same synthetic thread; attach Project Brief.pdf and wait for upload completion; inspect the composer in standard light and dark; send “Please review the attached PDF.”; inspect the sent attachment and reply’s PDF markdown link in light, dark, and a contrasting blue-bubble theme; force a second PDF upload to fail and inspect its red error state in light and dark.
Environment for every capture: Linux, 1280×800 CSS pixels, DPR 2; standard light/dark appearance unless labelled contrasting bubble. Each commit ran from its own checkout and initially empty isolated database. Only the replay reply fixture was adjusted; rendering code was not modified. Every still passed two identical screenshots 500 ms apart and was visually inspected. Paired frames differ only in successful PDF text.
Observed on both surfaces: base gives successful PDF names, sizes, and reply links red text; head uses surrounding text colour and keeps the PDF icon red. Failed uploads remain red. Contrasting-theme frames show actual blue-bubble rendering, but the message-ink override branch remains unverified because these PDF chips render as tooltip triggers.
AI-assisted; verified with the tests and tools listed above.
Not shown:
Origin/main freshness: both fetch attempts returned "error: RPC failed; HTTP 503 curl 22 The requested URL returned error: 503" and "fatal: expected 'acknowledgments'". The tested base matches the local origin/main merge-base with head.
The --context-chip-message-ink override branch, including other chip kinds under that override, remains unverified. In the real contrasting-theme run --context-chip-message is white, but PDF chips render as data-slot=tooltip-trigger, so the ancestor data-slot=context-chip selector does not activate the override. Actual contrasting-bubble PDF rendering is captured on both commits.
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:S10-29 changed lines (additions + deletions).vouch:trustedPR author is trusted by repo permissions or the VOUCHED list.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ContextChip painted the label (filename and size) in the kind's accent via --context-chip-ink. The doc-pdf accent (oklch 0.62 0.16 24) resolves to almost the same red as --context-chip-invalid (errorForeground), so a healthy PDF chip looked like a failed one. Fix in ContextChip.tsx: the doc-pdf kind sets --context-chip-ink to currentColor and points --document-icon-stroke at the accent, so only the PDF icon stays red. The invalid state now sets --context-chip-ink to the accent itself, so invalid chips of any kind, PDFs included, still have red labels. Sent-message bubbles (TimelineUserMessageRow BUBBLE_CHIP_CLASS_NAME) used to override --context-chip-ink with --context-chip-message on the descendant chip, which the doc-pdf class would now beat. That override moves to a new --context-chip-message-ink variable that the base, doc-pdf and invalid ink and stroke values read first, so bubble behaviour is unchanged for every kind. Reproduced on main with a temporary browser test: the PDF chip label computed to the PDF accent. After the fix it computes to the surrounding colour while the icon stroke keeps the accent. Invalid PDF chips stay red; mention chips and bubbles with or without --context-chip-message behave as before. No new regex or parser. The scratch test was not committed: AGENTS.md says colour-only bugs are proven with before/after captures, not UI tests. No captures were taken in this step. The first push failed with a git.cafe credential lookup error (the global credential config sets usehttppath=true and the stored entry has no path); it succeeded with -c credential.https://git.cafe.usehttppath=false on that one command.
Fixes #33044
Reproduction on main
Commit bcee0f5 (origin/main). Fresh worktree,
vp i,T3CODE_DEV_SEED=0 vp run dev(fresh empty database), paired a browser through the startup pairing URL, default light theme. On the new-thread composer I clicked 'Attach files' and uploaded a minimal valid one-page PDF (report.pdf, 193 bytes); the upload request returned 204. The composer chip 'File attachment, report.pdf, 1 KB' renders the PDF icon, the filename and the '1 KB' size all in red: computed colour of the label and size spans is rgb(179,55,57) (#b33739), while the text around it is near-black (oklch 0.21). On the same page --context-chip-doc-pdf resolves to #b33739 and --context-chip-invalid (the colour of a failed chip, from errorForeground) to #c10007, so a healthy PDF chip and a failed chip are nearly the same red. I did not send the message, so I did not check the sent-message bubble, and I did not check desktop or a custom theme.Evidence
Evidence
On both fresh apps: create a new thread, type “Please review these attachments: ”, attach the same 193-byte report.pdf and notes.txt, then send using the free replay fixture. After completion, attach both files again in the composer and attach failed.pdf with its upload deliberately interrupted. Restore normal uploads, then capture the settled sent bubble and composer in each appearance below.
Every capture uses the real web dev app, Linux, headless Chrome 151.0.7922.108, a 1280×800 viewport, local direct connection, and fresh checkout-local databases started with
T3CODE_DEV_SEED=0. Synthetic data only. Each still passed a byte-identical screenshot comparison at least 500 ms apart and uses the same automatic 1024×685 privacy crop. Custom light palette: canvas#f1f5f9, text#16324f, message surface#dce8f3, message foreground#17476b, error foreground#b00020.Across these captures, healthy PDF filenames and sizes lose their red on head in both locations, while PDF icons retain their red cue. Invalid PDF chips remain red. The notes.txt control retains exactly the same colour on both commits. Default-light base PDF text is
rgb(179,55,57), close to invalidrgb(193,0,7); head PDF text is neutral. Both sides completed four real attachment uploads with HTTP 204. This is static rendering evidence; no tests substitute for the images.Executed standalone driver and seed · Fresh-checkout rebuild helper · Environment and observations
All six images were opened and inspected before upload. Downloaded uploads matched their local artifacts byte-for-byte. AI-assisted; verified with the tests and tools listed above.
Not shown:
Checks run
Temporary browser test (vp test run, chromium), not committed: failed on main (PDF label rgb(200,0,0), the accent, instead of the surrounding colour) and passed after the fix. It checked healthy and invalid PDF chips, a mention chip, and bubble chips with and without --context-chip-message. vp test run src/components/ContextChip.browser.test.tsx: pass. vp run check:changed: format, lint, knip 1/2 and 2/2, typecheck (2 packages), test (1 file), react compiler (2 files): all pass.
Not included
AI-assisted; verified with the tests and tools listed above.