Repository navigation
fix(builder): drop the platform-wrong keystroke hint and hold the roving stop at focus - #1029
Conversation
…ing stop at focus The tooltip named Ctrl+D while the binding is spelled `mod`, which the shortcut manager resolves to Command on Apple platforms. A Mac author was being taught a keystroke that does nothing. The one rule that answers this is the manager's own detectApplePlatform, which is not on @nextlyhq/ui's public entry, and spelling the platform a second time here would let a tooltip disagree with the binding it describes. The roving tab stop reset to the first button whenever the selection moved. Duplicate and Select parent both move it while the author's focus is still on the button they pressed, so the stop and the caret ended up on different buttons and the next arrow press jumped backwards.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
Next review available in: 27 seconds Limit details: You’ve used all 1 included review currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
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. Comment |
Fallow audit reportFound 40 findings. Details
Generated by fallow. |
Two defects in #1025, found by reviewing my own diff after both review bots hit their usage limits and never ran on it.
These fixes existed before #1025 merged but did not make it in. #1025 was merged at
09:04:44Zon head17c181a32; I pushed the fixes at10:03once4a06158, after the merge, so they were stranded on a branch nobody would look at again. That sequencing was my error — I kept working on a PR without re-checking whether it was still open. This recovers them by cherry-pick onto currentmain.1. The tooltip taught a keystroke that does nothing on macOS
It showed
Ctrl+D. The binding is spelledmod, andkey-spec.tsresolvesmodto Command on Apple platforms, Control elsewhere. So on a Mac the tooltip named a keystroke that does nothing, for the one action an author is most likely to try to learn.The original justification — that resolving per platform would be "a second place that decides what the key is" — conflated two different jobs: which key the BINDING is (the shortcut manager's), and how to SPELL it for a human (a display concern). Getting the second wrong is not excused by owning the first.
The right rule already exists:
detectApplePlatforminpackages/ui/src/lib/shortcuts/key-spec.ts. It is not on@nextlyhq/ui's public entry, sopackages/buildercannot reach it, and spelling the platform a second time here would let a tooltip disagree with the binding it describes. So the hint is removed rather than guessed, with a comment recording what would bring it back. The tooltip keeps the action name and, when unavailable, the reason — which is the load-bearing content.For context, not fixed here: the admin hardcodes
⌘inRequestBar.tsx, which is wrong on Windows and Linux for the same underlying reason.2. The roving tab stop fought the caret
The stop reset to the first button whenever the selection moved. But Duplicate and Select parent both move the selection while the author's focus is still on the button they pressed — so the roving index and the caret ended up on different buttons, and the next arrow press jumped backwards from where the author was looking.
Now the reset is skipped while the bar contains focus, where
onFocushas already put the index in the right place.Verified
Both fixes stub-verified in both directions, each caught by exactly the test whose name claims it:
The second test is the control for the first: without it, the fix would pass against a bar that had simply stopped resetting the stop at all, stranding it on a button belonging to a block the author has moved on from.
packages/builder: 683 tests, types and lint clean. Built to completion first, then gated as separate commands —check-typesdepends on^check-typesandlinton nothing, so neither builds what it reads.