Skip to content

Conversation

@deepakbhagatiitr
Copy link

@deepakbhagatiitr deepakbhagatiitr commented Dec 6, 2025

This update adds configurable Enter-key behavior for tablet and iPad users. They can now choose whether pressing Enter should send the message or insert a newline, directly from the Preferences tab. The feature is tablet and iPad -only and mirrors the behaviour of the send button whenever “Enter to Send” is enabled.

Closes #746

Key Changes

  • Added a preference allowing users to select “Send on Enter” or “Insert newline.”
  • Implemented sendViaEnterKey in ComposerInput to update state and run the shared sendMessage pipeline.
  • Limited this setting to tablet and iPad devices only.

Demo Videos

For Ipad

For Tablet

Summary by CodeRabbit

  • New Features
    • Added Enter key behavior preference for tablets in Accessibility and Appearance settings, enabling users to choose between sending messages or creating new lines when pressing Enter.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 6, 2025

Walkthrough

The changes implement an Enter key behavior preference feature allowing users to select between sending messages or creating new lines when pressing Enter. This includes preference storage via a new constant key, tablet-specific UI settings, complex Enter key interception in the message composer, and localization strings.

Changes

Cohort / File(s) Summary
Message Composition Logic
app/containers/MessageComposer/components/ComposerInput.tsx
Added context-based sendMessage integration, ref-based state coordination (shouldInterceptEnterRef, previousTextRef, isUpdatingNativePropsRef), tablet-specific Enter-key behavior reading from preferences, and new text update flow with sendViaEnterKey synchronization via requestAnimationFrame. Complex onChangeText and onKeyPress handlers added to manage Enter key interception and newline blocking.
Preference Storage & Constants
app/lib/constants/keys.ts
Added new exported constant ENTER_KEY_BEHAVIOR_PREFERENCES_KEY with value 'RC_ENTER_KEY_BEHAVIOR_PREFERENCES_KEY' for persistent storage of Enter key behavior preference.
Localization
app/i18n/locales/en.json
Added three new i18n keys: Enter_key_behavior ("Enter key behavior"), Enter_key_send_message ("Send message"), and Enter_key_new_line ("New line").
Settings UI Components
app/views/AccessibilityAndAppearanceView/components/ListPicker.tsx
Refactored ListPicker to support generic typing with constraint <T extends TAlertDisplayType | TEnterKeyBehavior>, added conditional mode selection ('alert' | 'enterKey'), and introduced separate option arrays (ALERT_OPTIONS vs ENTER_KEY_OPTIONS) with corresponding TEnterKeyOptions type definition.
Accessibility Settings View
app/views/AccessibilityAndAppearanceView/index.tsx
Added tablet-only UI rendering for Enter key behavior preference, exported TEnterKeyBehavior type ('SEND' | 'NEW_LINE'), added enterKeyBehavior state management with default 'NEW_LINE', and imported the new preference key constant. Updated useLayoutEffect dependency array.
Build Configuration
ios/RocketChatRN.xcodeproj/project.pbxproj
Removed quotes around path literals in Bugsnag script inputPaths and Firebase HEADER_SEARCH_PATHS for XCBuildConfiguration blocks (cosmetic refactoring).

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

  • ComposerInput.tsx: Requires careful review of ref-based state coordination, Enter key interception logic, and the timing of microtask-based flag clearing to ensure no race conditions or missed events
  • ListPicker.tsx: Generic type constraint and conditional option set selection need verification to ensure type safety across both modes
  • Cross-component integration: Verify consistency between preference storage key, UI updates, and consumption in the message composer; check that defaults align

Suggested reviewers

  • OtavioStasiak
  • diegolmello

Poem

🐰 A rabbit hops with keys in paw,
Enter sends or lines anew—
Preferences bound without a flaw,
Tablets dance in gentler hue!
🎹✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Out of Scope Changes check ⚠️ Warning The Xcode project file changes (removing quotes from build paths) appear unrelated to the Enter-key behavior feature and may constitute scope creep beyond the intended tablet preference feature. Review whether the iOS build configuration changes are necessary for this feature or should be submitted as a separate PR to maintain focused scope.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly summarizes the main feature: adding configurable Enter-key behavior for tablet users, which is the primary objective of the changeset.
Linked Issues check ✅ Passed The PR successfully implements the core requirement from issue #746: a user-configurable Enter-key behavior option allowing users to choose between sending messages or inserting newlines on tablets.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (3)
ios/RocketChatRN.xcodeproj/project.pbxproj (1)

1737-1738: Prefer keeping these paths quoted for consistency with the rest of the project file

The unquoted $TARGET_BUILD_DIR/$INFOPLIST_PATH and $PODS_CONFIGURATION_BUILD_DIR/Firebase entries will likely still work, but almost all other inputPaths/HEADER_SEARCH_PATHS here are quoted. Re-quoting them would avoid surprises with Xcode parsing and keep the file style uniform.

Also applies to: 1823-1824, 2605-2606, 2683-2684

app/views/AccessibilityAndAppearanceView/components/ListPicker.tsx (1)

10-11: Generic ListPicker works for current uses but typing could be tightened

The genericization and dual option sets (alert vs enterKey) look correct for the two current call sites, and the runtime behavior is sound. Two follow-ups you might consider:

  • Tie type and T more strongly in the types so it’s impossible to accidentally call ListPicker with value: TEnterKeyBehavior but type omitted (which would silently pick ALERT_OPTIONS). For example, a discriminated union like:
    type ListPickerProps =
      | { type?: 'alert'; value: TAlertDisplayType; onChangeValue: (v: TAlertDisplayType) => void }
      | { type: 'enterKey'; value: TEnterKeyBehavior; onChangeValue: (v: TEnterKeyBehavior) => void };
    and then drop the generic.
  • Hoist ALERT_OPTIONS and ENTER_KEY_OPTIONS outside the component so they aren’t recreated on every render (tiny perf/readability win).

Also applies to: 38-39, 41-44, 46-55, 58-59, 71-82, 84-87, 97-100

app/views/AccessibilityAndAppearanceView/index.tsx (1)

17-21: Tablet enter-key preference wiring looks correct

Importing ENTER_KEY_BEHAVIOR_PREFERENCES_KEY, defining TEnterKeyBehavior, and binding enterKeyBehavior to a tablet-only ListPicker matches the intended feature: tablets can choose between send vs newline while phones remain unchanged. Updating the useLayoutEffect deps to include isMasterDetail is also a good correctness fix.

You may later want to centralize TEnterKeyBehavior in a shared types module so ComposerInput can reuse it instead of repeating 'SEND' | 'NEW_LINE', but that’s purely a maintainability improvement.

Also applies to: 23-25, 32-39, 60-68, 126-139

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

  • Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 1bd62a2 and 5728844.

⛔ Files ignored due to path filters (1)
  • ios/Podfile.lock is excluded by !**/*.lock
📒 Files selected for processing (6)
  • app/containers/MessageComposer/components/ComposerInput.tsx (7 hunks)
  • app/i18n/locales/en.json (1 hunks)
  • app/lib/constants/keys.ts (1 hunks)
  • app/views/AccessibilityAndAppearanceView/components/ListPicker.tsx (4 hunks)
  • app/views/AccessibilityAndAppearanceView/index.tsx (4 hunks)
  • ios/RocketChatRN.xcodeproj/project.pbxproj (4 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
app/views/AccessibilityAndAppearanceView/index.tsx (2)
app/lib/methods/userPreferences.ts (1)
  • useUserPreferences (10-10)
app/lib/constants/keys.ts (1)
  • ENTER_KEY_BEHAVIOR_PREFERENCES_KEY (23-23)
app/views/AccessibilityAndAppearanceView/components/ListPicker.tsx (1)
app/views/AccessibilityAndAppearanceView/index.tsx (2)
  • TAlertDisplayType (23-23)
  • TEnterKeyBehavior (24-24)
🔇 Additional comments (3)
app/i18n/locales/en.json (1)

796-798: Enter-key i18n strings are consistent and clear

Keys and copy match existing naming/style and cover the behavior, send, and newline labels needed by the new picker.

app/lib/constants/keys.ts (1)

18-25: New ENTER_KEY_BEHAVIOR preference key is consistent

The new ENTER_KEY_BEHAVIOR_PREFERENCES_KEY follows the existing naming and namespacing pattern for preferences keys and is suitable for reuse across views and the composer.

app/containers/MessageComposer/components/ComposerInput.tsx (1)

1-1: Enter-to-send implementation on tablets is well integrated; consider minor simplifications and manual QA

The new behavior in ComposerInput—reading ENTER_KEY_BEHAVIOR_PREFERENCES_KEY, intercepting a trailing \n on tablets when behavior is SEND, trimming it, and delegating to sendMessage()—aligns with PR goals and reuses the existing send pipeline via MessageInnerContext, which is good.

A few minor points to consider:

  • The combination of shouldInterceptEnterRef, previousTextRef, and the text.endsWith('\n') && text.slice(0, -1) === previousText check provides cross-platform Enter detection (onKeyPress for Android, diff-based for iOS). Before merging, explicitly verify:
    • iOS/iPadOS with hardware keyboard (ensure onKeyPress + diff behave consistently).
    • Editing in the middle of a message vs at the end (current logic only intercepts appended newlines, which is correct but worth confirming in QA).
  • isUpdatingNativePropsRef with the 0ms setTimeout guard prevents recursive onChangeText calls but adds complexity. Monitor for flakiness on rapid typing; a more targeted approach (tracking "last programmatic text" and ignoring only that exact next call) may be preferable if issues arise.
  • The union type 'SEND' | 'NEW_LINE' is hard-coded here while TEnterKeyBehavior is exported from AccessibilityAndAppearanceView. Consolidate by moving the type to a shared module and importing it in both places to prevent future drift.

Recommended manual tests:

  1. iPad/tablet, setting = "Send message": Type "hello" and press Enter → message sends, input clears. Press Enter on empty input → nothing sent. Move cursor mid-text and press Enter → newline inserted (no send).
  2. iPad/tablet, setting = "New line": Press Enter anywhere → newline inserted, never sends.
  3. Phone (non-tablet), any keyboard: Enter always inserts newline; sending requires tapping send button.
  4. External hardware keyboard on iPad: Repeat tests (1)–(2) to ensure behavior matches on-screen keyboard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Option to send or to make a new line when pressing the enter key in the virtual/hardware keyboard

1 participant