Fix mobile Answer edge dock hide and reveal#1192
Conversation
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
Warning Review limit reached
Next review available in: 29 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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 selected for processing (1)
📝 WalkthroughWalkthroughThe PR adds geometry-aware mobile chrome collapse handling, distinguishes in-flow and reserve-only behavior, synchronizes header and composer pinning, refines composer autofocus retention, and adds unit, UI smoke, contract, and review-ledger coverage. ChangesMobile chrome behavior
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant ScrollContainer
participant phoneScrollHide
participant computeScrollHideUpdate
participant HeaderAndComposer
User->>ScrollContainer: scroll or focus main
ScrollContainer->>phoneScrollHide: report offset, maxOffset, and collapse metrics
phoneScrollHide->>computeScrollHideUpdate: evaluate collapse kind and prior max offset
computeScrollHideUpdate->>HeaderAndComposer: update synchronized hidden state
HeaderAndComposer->>User: hide or reveal header and composer
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 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. Comment |
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
CI triageCI failed on this PR. Automated classification of the 2 failed job(s):
Compared with main CI run #5615 (success). Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger. |
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
…scroll-5b1d' into cursor/fix-mobile-composer-edge-scroll-5b1d Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
cursor
Bot
changed the title
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
On a starved CI renderer the single upward scrollTop write coalesced into the trailing bottom-clamp evaluation, and the shrinking-range hold rebased it away as geometry feedback, so the reveal never fired. A real drag always emits follow-up events; model that with two separated upward steps that each yield frames.
…shold RAF debouncing coalesces a layout-clamp scroll event with any immediately following user scroll into one RAF evaluation. The hook reads the final offset (newMaxOffset - userScroll) but lastMaxOffsetRef still holds the pre-collapse maximum so the clamp detection incorrectly fires: lastOffset (V) > newMaxOffset (V-72) ← old position above new max offset (V-96) < lastOffset (V) ← apparent upward movement maxOffset (V-72) < previousMaxOffset (V) ← range shrank All three conditions are true even though the upward movement includes a genuine 24px user scroll on top of the geometry-driven clamp. Guard the clamp detection with offset >= maxOffset - revealIntentDistance: only treat the movement as pure geometry feedback when the net position lands within revealIntentDistance (12px) of the new bottom edge. If the combined offset is already more than 12px below the new max the user has supplied enough upward intent to reveal regardless of the clamp. Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
…dger Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
…scroll-5b1d' into cursor/fix-mobile-composer-edge-scroll-5b1d Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
…poser-edge-scroll-5b1d # Conflicts: # src/components/clinical-dashboard/global-search-shell.tsx Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
…scroll-5b1d' into cursor/fix-mobile-composer-edge-scroll-5b1d Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
…poser-edge-scroll-5b1d Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
Merging current main into this branch let the union driver append two records that both sides already carried, which fails check:branch-review-ledger. Both copies of each record were byte identical, so the later copy goes and the unique record set is unchanged at 938.
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/branch-review-ledger.md`:
- Line 991: Correct the future-dated audit record dates in
docs/branch-review-ledger.md at lines 991, 994, 996, and 1000 to the current
date, July 25, 2026, unless the entries are intentionally deferred until the
work occurs; update all four records consistently.
In `@tests/ui-smoke.spec.ts`:
- Around line 3865-3879: Replace the direct scrollTop and RAF logic in the
reveal loop with the existing scrollPrimarySurface helper for both upward steps,
preserving the settledBottomOffset-based targets and 24/48 rise sequence. Ensure
each helper call dispatches the scroll event and waits for the browser task as
intended.
🪄 Autofix (Beta)
✅ Autofix completed
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: def393df-104f-45ef-a45a-b943ea7e68a6
📒 Files selected for processing (8)
docs/branch-review-ledger.mddocs/search-chrome-behaviour.mdsrc/components/ClinicalDashboard.tsxsrc/components/clinical-dashboard/global-search-shell.tsxsrc/components/clinical-dashboard/master-search-header.tsxsrc/components/clinical-dashboard/use-hide-on-scroll.tstests/ui-smoke.spec.tstests/use-hide-on-scroll.test.ts
🚧 Files skipped from review as they are similar to previous changes (4)
- src/components/clinical-dashboard/global-search-shell.tsx
- docs/search-chrome-behaviour.md
- src/components/clinical-dashboard/master-search-header.tsx
- src/components/clinical-dashboard/use-hide-on-scroll.ts
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. ❌ Cannot run autofix: This PR has merge conflicts. Please resolve the conflicts with the base branch and try again. Alternatively, use |
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. The branch was updated while autofix was in progress. Please try again. |
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. Fixes Applied SuccessfullyFixed 1 file(s) based on 1 unresolved review comment. Files modified:
Commit: The changes have been pushed to the Time taken: |
Fixed 1 file(s) based on 1 unresolved review comment. Co-authored-by: CodeRabbit <noreply@coderabbit.ai>
#1224 and the #1192 landing (#1232) * docs(ledger): batch the appends from PRs #1206, #1207, #1210, #1211 and #1224 Five open PRs each append review records to docs/branch-review-ledger.md and nothing else. Each one has to be synced against main and carried through a full CI cycle, and every sync risks the union driver re-duplicating rows, so the queue cost far exceeds the fifteen lines involved. Rows are copied verbatim from each PR head and verified byte-identical, so the original PRs can be closed as landed here rather than merged individually. * docs(ledger): record PR #1192 prlanded squash merge
2 participants
Summary
composerChromeFocusedwhen the phone dock tears down without blur, and refuse near-bottom reserve-only hides that would clamp content under the finger.RAG impact: no retrieval behaviour change — search-chrome / mobile dock UX only; ranking, retrieval, and answer generation are untouched.
Verification
node scripts/run-vitest.mjs run tests/use-hide-on-scroll.test.ts tests/mobile-composer-reserve.test.ts(28/28) before and after merging currentmainnpm run verify:pr-local/npm run verify:uinot re-run after the latest main merge; hosted CI will re-validate on this headRisk and rollout
Clinical Governance Preflight
Clinical KB Database(sjrfecxgysukkwxsowpy)Notes
5b5ecf405and retained through the main sync.focus=1autofocus remains broader than Answer-mode; earlier document-detail double-header notes are out of this PR's Answer-dock scope.Summary by CodeRabbit
focus=1) with safer autofocus pinning/cleanup to avoid accidental blur.