Sign up
View stargazersSign up

fix(mobile): upgrade react-native-keyboard-controller to 1.22.8 for the Duo fold composer#25141

merged2
main
t3code/duo-fold-composer-offset
opened5d agobyJJulius Marminge
4 files changed
View on GitHubTwo-way sync enabledPR last imported 5d ago

After rotating and folding the iPhone Duo, the thread composer could land below the vertical bar's rail and stay there until the keyboard opened again.

Cause

On a foldable iPhone, iOS posts keyboardWillShow with a zero-height frame when the display changes. react-native-keyboard-controller 1.22.7 reported that as a fully open keyboard (progress 1, height 0), so KeyboardStickyView kept its open offset. That offset is the composer's bottom spacing: 18 pt on the unfolded Duo. Logged in the simulator, this happened on most fold cycles with the composer focused.

Fix

Upgrade to 1.22.8, which includes the upstream fix (kirillzyusko/react-native-keyboard-controller#1677, written for this foldable case). Our local patch is ported. 1.22.8 rewrote the scroll-target clamp in useExtraContentPadding, so that hunk was reapplied by hand in the source and both builds. The rest applied unchanged.

Before

From the simulator, after rotating and folding (composer below the rail):

Before: composer sits below the rail after a fold

After

Native client rebuilt with 1.22.8, then four fold cycles with the composer focused. Progress never stuck at 1, and the composer stays level with the rail:

After: composer level with the rail after folding

Not fixed here

On one of the four folds, iOS reported a 263 pt keyboard on the inner display that it never drew. The app showed its keyboard-dismiss button in the rail, and the composer floated mid-screen until the next fold. This also happens on 1.22.7, so it's a separate issue with the keyboard frame iOS reports when the display changes.

The native change requires a new build; it does not ship as an OTA. vp run check:changed passes.

Claude Opus 5.5 in Claude Code, running in T3 Code.

🤖 Generated with Claude Code

Checks

25 successful · 11 skipped
All checks passed
07ac400

Added 1 commit

  • fix(mobile): the composer stays level with the Duo's rail after a foldf05f8a5
MmacroscopeappBot5d ago
Synced from GitHub

Approvability

Verdict: Approved at 07ac400

Macroscope's review found this PR approvable — This PR upgrades and reapplies the existing keyboard-controller patch to fix a focused iOS fold/keyboard layout defect. Its runtime impact is confined to existing keyboard inset and scroll handling, with dependency metadata kept consistent and no product-default or static-analysis changes.

You can add or adjust custom eligibility rules. Learn more.

CcoderabbitaiBot5d ago
Synced from GitHub

Review in Change Stack →

No actionable comments were generated in the recent review.

External image Recent review info
External image Run configuration
External image Commits

Reviewing files that changed from the base of the PR and between 481b9b71929b2c7c9f120712a3264fe218cf2b95 and f05f8a5d556480ad06efc77cbd3ad301f7e03e17.

External image Files selected for processing: 3
  • apps/mobile/src/components/KeyboardStickyView.tsx
  • apps/mobile/src/features/threads/ThreadDetailScreen.tsx
  • apps/mobile/src/features/workspace/WorkspaceToolbar.tsx

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 1 remain after this review.

Walkthrough

The pull request adds a local KeyboardStickyView component that calculates vertical translation from keyboard height and offsets. ThreadDetailScreen and WorkspaceToolbar now import it from the local component module.

Changes: Mobile keyboard sticky view

Layer / File(s)Summary
Implement keyboard-aware translation
apps/mobile/src/components/KeyboardStickyView.tsx		Adds KeyboardStickyView. It interpolates between closed and open offsets based on keyboard progress when keyboard height is negative. When disabled, it uses only the closed offset.
Use the local component
apps/mobile/src/features/threads/ThreadDetailScreen.tsx, apps/mobile/src/features/workspace/WorkspaceToolbar.tsx		Both screens import KeyboardStickyView locally. Their other keyboard-controller imports remain.

Priority: External image Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related issues

  • pingdotgg/t3code#22484 — The change avoids applying the open offset when keyboard height is zero, which overlaps with the reported stale keyboard progress behavior.
  • pingdotgg/t3code#22751 — Both involve mobile content positioned relative to the keyboard, but the issue describes a different Android split-screen route and does not establish the same cause.
  • pingdotgg/t3code#24290 — Both involve keyboard-related layout in ThreadDetailScreen; the issue concerns a stale keyboard-height reserve while the keyboard is closed.

Suggested labels: size:M

Suggested reviewers: macroscopeapp

Merge Risk: External image Minimal · up to f05f8

The fold-layout fix is mergeable after normal checks. The separately reported keyboard-not-drawn behavior still needs investigation.

Pre-merge checks: Passed 3 · Failed 1

Failed Failed checks: 1 warning

Check nameStatusExplanationResolution
Description checkWarningThe description clearly explains the problem, cause, fix, verification steps, screenshots, observed results, and known limitation. It does not include the required Scope and approval section or a repo…Add a Scope and approval section. Link the triaged repository issue or maintainer approval, or explain why this focused fix qualifies for an exemption.
Passed Passed checks: 3 passed
Check nameStatusExplanation
Linked Issues checkPassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes checkPassedCheck skipped because no linked issues were found for this pull request.
Title checkPassedThe title clearly identifies the mobile keyboard-controller upgrade and connects it to the Duo fold composer issue.
Full details: Description check

Explanation

The description clearly explains the problem, cause, fix, verification steps, screenshots, observed results, and known limitation. It does not include the required Scope and approval section or a repository issue and maintainer approval.

Resolution

Add a Scope and approval section. Link the triaged repository issue or maintainer approval, or explain why this focused fix qualifies for an exemption.

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

Comment @coderabbitai help to get the list of available commands.

Added 1 commit

  • fix(mobile): upgrade react-native-keyboard-controller to 1.22.807ac400
Ggithub-actionsBot5d ago
Synced from GitHub

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ProviderMetricMain baselineThis PRImpactPR ceiling
CodexTotal thread wire5.0 KiB5.0 KiB−7 B (−0.1%)6.8 KiB✅
CodexThread snapshot wire3.8 KiB3.8 KiB0 B (0.0%)4.9 KiB✅
CodexLive turn WebSocket wire1.2 KiB1.2 KiB−7 B (−0.6%)2.0 KiB✅
CodexLive turn WebSocket decoded20.9 KiB20.9 KiB0 B (0.0%)29.3 KiB✅
CodexLive turn messages220 (0.0%)8✅
ClaudeTotal thread wire5.0 KiB5.0 KiB−7 B (−0.1%)6.8 KiB✅
ClaudeThread snapshot wire3.8 KiB3.8 KiB0 B (0.0%)4.9 KiB✅
ClaudeLive turn WebSocket wire1.2 KiB1.2 KiB−7 B (−0.6%)2.0 KiB✅
ClaudeLive turn WebSocket decoded21.2 KiB21.2 KiB0 B (0.0%)29.3 KiB✅
ClaudeLive turn messages220 (0.0%)8✅

Baseline: 481b9b7 · PR result: 07ac400 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

  • Codex decoded thread snapshot: 108.5 KiB
  • Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.