keyboardtype parity to paper in fabric #15359

Nitin-100 · 2025-11-12T05:03:50Z

Description

Type of Change

New feature (non-breaking change which adds functionality)

Why

The keyboardType prop is a standard React Native TextInput property that allows developers to specify which keyboard type to display (e.g., numeric, email, phone pad). This prop was already defined and parsed in Fabric's WindowsTextInputProps but was not being applied to the native component, creating a parity gap with Paper (XAML) implementation where it is fully functional.

Current Status:

Paper (XAML): Fully implemented with InputScope support
Fabric (Composition): Prop defined and parsed but NOT applied ← This PR fixes this

This change is part of the ongoing effort to achieve feature parity between Paper and Fabric architectures for TextInput components.

What

This PR implements proper handling of the keyboardType prop in Fabric's TextInput component:

Files Modified:

WindowsTextInputComponentView.h
- Added updateKeyboardType() method declaration
- Added m_keyboardType member variable to store the keyboard type
WindowsTextInputComponentView.cpp
- Implemented updateKeyboardType() method to store the keyboard type value
- Added keyboard type update logic in updateProps() to detect prop changes
- Added keyboard type initialization in onMounted() for initial setup

Implementation Approach:
Since Fabric uses windowless RichEdit controls with TextServices (not XAML controls), and Windows.UI.Xaml.Input.InputScope is not available in Composition architecture, this implementation stores the keyboard type value to maintain the prop contract. The keyboard behavior is primarily handled by the system's Input Method Editor (IME).

Supported Keyboard Types:

Cross-platform: default, numeric, number-pad, decimal-pad, email-address, phone-pad, url
Windows-specific: web-search
Password mode: Handles different keyboard types when secureTextEntry is enabled

Screenshots

keyboardtype.mp4

Verify that:

The prop is properly stored and tracked
Changing the prop triggers updateKeyboardType()
No regressions in existing TextInput functionality

Changelog

Should this change be included in the release notes: Yes

Summary for release notes:
Added support for keyboardType prop in Fabric TextInput to achieve parity with Paper implementation. This standard React Native prop now properly handles keyboard type specification (numeric, email, phone, etc.) in Fabric architecture.

Microsoft Reviewers: Open in CodeFlow

acoates-ms · 2025-11-12T16:03:27Z

vnext/Microsoft.ReactNative/Fabric/Composition/TextInput/WindowsTextInputComponentView.h

  HCURSOR m_hcursor{nullptr};
  std::chrono::steady_clock::time_point m_lastClickTime{};
  std::vector<facebook::react::CompWindowsTextInputSubmitKeyEventsStruct> m_submitKeyEvents;
+  std::string m_keyboardType{};


We should not be storing copies of props on the component. The value already exists in the prop object, lets not duplicate memory.

acoates-ms

This PR does nothing. It just duplicates the prop storage, and doesn't implement the functionality of this prop.

Nitin-100 · 2025-11-13T03:02:27Z

This PR does nothing. It just duplicates the prop storage, and doesn't implement the functionality of this prop.

Yes, it is not complete and I was just trying to explore but windowless RichEdit controls do not support InputScope. This feature requires XAML controls (Paper architecture) or a future Windows platform API that supports windowless input scope hints.

Nitin-100 · 2025-11-13T03:06:00Z

Can't use TSF by using InputScope APIs (ITfContextOwner, ITfInputScope) but require a window handle (HWND), but Fabric is windowless.
I think we cannot implement it at all, partially we can restrict via filtering input like for numeric only keyboard and others, but not a good way.

- Implement SetInputScopes on parent HWND when TextInput gains focus - Reset InputScope to default when TextInput loses focus - Map all React Native keyboardTypes to Windows InputScope values - Add KeyboardTypeTest.tsx sample for testing - Add implementation documentation Note: API calls succeed but Windows desktop Touch Keyboard may not respond to InputScope changes. This is a known Windows platform limitation that also affects web browsers. Works on Windows tablets.

…flow - Add LogToFile() function that writes to keyboard_debug.log in the exe directory - Add logging in onGotFocus and updateKeyboardType to trace keyboard type flow - Fix touch identifier overflow by normalizing pointer ID with modulo 21 - This helps debug why touch keyboard layout may not change on touchscreen devices

- Implement ITfInputScope interface on CompTextHost for TSF integration - TSF (Text Services Framework) can now query InputScope directly - Add GetCurrentInputScope() method to WindowsTextInputComponentView - Store current InputScope in m_currentInputScope member - Add logging when ITfInputScope::GetInputScopes is called - This enables Touch Keyboard to show appropriate layout based on keyboardType

- Log when we successfully query ITfInputScope from m_textHost - This verifies our ITfInputScope implementation is properly exposed - Helps diagnose why TSF/Touch Keyboard doesn't query our InputScope

- Create ITfThreadMgr to understand TSF state - Query GetFocus to see if there's a focused document - Query GetTop to get the active context - This helps diagnose if TSF is properly integrated with our control

Since windowless RichEdit doesn't register with TSF (GetFocus returns no document), we create a hidden EDIT control that: 1. Has the correct InputScope set on it 2. Gets Windows focus when our TextInput gets focus 3. Forwards keyboard input to our RichEdit via subclassing 4. Touch Keyboard queries this EDIT and shows the correct layout This works around the limitation that SetInputScopes on parent HWND has no effect when there's no TSF DocumentMgr associated with it.

…extInput - Use WS_EX_TRANSPARENT | WS_EX_LAYERED with 0 alpha for invisibility - Use WS_VISIBLE flag which is required for proper TSF integration - Position proxy EDIT at the TextInput location instead of off-screen - Add TSF check after SetFocus to verify document manager registration

…d ITfInputScope

Nitin-100 · 2026-01-16T07:31:50Z

@acoates-ms I tried few ways to do the keyboard parity work for windowless, please see this video, the whole keyboard still remains same but with different options. Is this fine?

keyboardTypeTest.mp4

…github.com/Nitin-100/react-native-windows into nitin/parity-fabric/textinput-keyboardtype

Nitin-100 requested a review from a team as a code owner November 12, 2025 05:03

Nitin-100 requested a review from acoates-ms November 12, 2025 05:04

Nitin-100 force-pushed the nitin/parity-fabric/textinput-keyboardtype branch from 6b080f9 to 882dede Compare November 12, 2025 06:32

acoates-ms reviewed Nov 12, 2025

View reviewed changes

acoates-ms requested changes Nov 12, 2025

View reviewed changes

microsoft-github-policy-service bot added the Needs: Author Feedback The issue/PR needs activity from its author (label drives bot activity) label Nov 12, 2025

microsoft-github-policy-service bot added Needs: Attention 👋 An issue that had been tagged "Needs: Author Feedback" has received activity (label applied by bot) and removed Needs: Author Feedback The issue/PR needs activity from its author (label drives bot activity) labels Nov 13, 2025

Nitin-100 marked this pull request as draft November 13, 2025 03:06

Nitin-100 closed this Jan 7, 2026

Nitin-100 removed the Needs: Attention 👋 An issue that had been tagged "Needs: Author Feedback" has received activity (label applied by bot) label Jan 7, 2026

Nitin-100 reopened this Jan 8, 2026

Nitin Chaudhary added 3 commits January 8, 2026 22:02

Add keyboardType prop support to Fabric TextInput for parity with Paper

8d1e0ab

Change files

b23de66

Nitin-100 force-pushed the nitin/parity-fabric/textinput-keyboardtype branch from 571882b to c1d0caf Compare January 8, 2026 16:33

Nitin Chaudhary added 11 commits January 9, 2026 08:28

Fix prettier formatting in KeyboardTypeTest.tsx

92b458b

Remove debug logging code from keyboardType implementation

765d2bc

Add debug logging to verify ITfInputScope implementation on CompTextHost

9ccb881

- Log when we successfully query ITfInputScope from m_textHost - This verifies our ITfInputScope implementation is properly exposed - Helps diagnose why TSF/Touch Keyboard doesn't query our InputScope

Add TSF ThreadMgr and DocumentMgr diagnostic logging

af59cbf

- Create ITfThreadMgr to understand TSF state - Query GetFocus to see if there's a focused document - Query GetTop to get the active context - This helps diagnose if TSF is properly integrated with our control

Clean up keyboardType implementation - remove debug logging and unuse…

f98b4b8

…d ITfInputScope

Fix formatting and code cleanup for keyboardType implementation

321bcfa

Remove keyboardType implementation summary doc

7499e0b

Merge branch 'main' into nitin/parity-fabric/textinput-keyboardtype

1fb5a49

Nitin-100 marked this pull request as ready for review January 19, 2026 07:48

Nitin Chaudhary and others added 4 commits January 19, 2026 13:22

Remove duplicate m_keyboardType member - use props directly

454fe16

Change files

9371bee

Merge branch 'main' into nitin/parity-fabric/textinput-keyboardtype

dc4035d

Merge branch 'nitin/parity-fabric/textinput-keyboardtype' of https://…

8af25cc

…github.com/Nitin-100/react-native-windows into nitin/parity-fabric/textinput-keyboardtype

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

keyboardtype parity to paper in fabric #15359

keyboardtype parity to paper in fabric #15359

Nitin-100 commented Nov 12, 2025 •

edited

Loading

Uh oh!

acoates-ms Nov 12, 2025

Uh oh!

acoates-ms left a comment

Uh oh!

Nitin-100 commented Nov 13, 2025 •

edited

Loading

Uh oh!

Nitin-100 commented Nov 13, 2025

Uh oh!

Nitin-100 commented Jan 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

keyboardtype parity to paper in fabric #15359

Are you sure you want to change the base?

keyboardtype parity to paper in fabric #15359

Conversation

Nitin-100 commented Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Type of Change

Why

What

Screenshots

Changelog

Microsoft Reviewers: Open in CodeFlow

Uh oh!

acoates-ms Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

acoates-ms left a comment

Choose a reason for hiding this comment

Uh oh!

Nitin-100 commented Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Nitin-100 commented Nov 13, 2025

Uh oh!

Nitin-100 commented Jan 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Nitin-100 commented Nov 12, 2025 •

edited

Loading

Nitin-100 commented Nov 13, 2025 •

edited

Loading