fix(one-page): leave no highlight after a cut-off note name in the file picker - #2127
Conversation
…le picker A long note name in a one-page file field is cut with an ellipsis, which hides a match's text but not its highlight background, so a small block showed after the "…". Matches there are now bold only, as in the run's own picker. Fixes #2124
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 5 remain after this review. 📝 WalkthroughWalkthroughThe one-page file-picker suggestion text now uses a transparent background for match highlights. An end-to-end test checks that the highlight remains transparent when a matching note name is clipped by the label ellipsis. ChangesFile-picker match highlight
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix · Severity of issue fixed: Low Merge Risk: ⚪ Minimal · up to The change addresses the clipped-highlight behavior with a scoped style and a focused regression test. No material merge risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. A rabbit searched for “zebra” in the night, Comment |
A one-page file field cuts a long note name with "…". When a highlighted match fell in the cut-off part, the ellipsis hid its text but not its highlight background, so a small lavender block showed after the "…". Matches in these rows are now bold with no background, as in the run's own Capture to picker, so a hidden match leaves nothing behind.
Repro: folder Capture to
People/with one-page input, a notePeople/Alexandria Ocasio-Cortez Long Name Example.md; run it, click Search files..., typeZed.The picker and its CSS date from #1643 and are unchanged since 2.29.0, but 2.30 puts this field in front of every one-page folder, tag and property Capture (#2099), where long names are common and the field is narrower on phones. The change is one CSS rule scoped to these rows; other
.qa-highlightuses keep their background.New native spec in
tests/e2e/one-page-capture-target.test.ts: it types a query that matches only the cut-off end of a long name and checks the highlight paints no background. It fails on master's CSS with the highlight colour and passes here.Checks:
pnpm run build-with-lint,pnpm run test(6603 passed),.agents/run-e2eon a clean vault (398 passed, 24 Templater-only skipped). No release or migration impact.Fixes #2124
Note
Fix stray highlight on cut-off note names in the one-page file picker
A scoped CSS rule makes the highlight background transparent when matched text is clipped by the ellipsis in one-page file suggestion labels. The highlight element and text styling stay unchanged. Adds an e2e test that searches for a match near the end of a long note name and verifies the clipped match shows no visible highlight (one-page-capture-target.test.ts).
Macroscope summarized b01d996.
Summary by CodeRabbit