Skip to content

Add runtime warning for unsupported keyboardType #15778

Open
Nitin-100 wants to merge 2 commits intomicrosoft:0.82-stablefrom
Nitin-100:nitinc/textinput-keyboardtype-warning
Open

Add runtime warning for unsupported keyboardType #15778
Nitin-100 wants to merge 2 commits intomicrosoft:0.82-stablefrom
Nitin-100:nitinc/textinput-keyboardtype-warning

Conversation

@Nitin-100
Copy link
Contributor

@Nitin-100 Nitin-100 commented Mar 16, 2026

Description:

Adds a runtime warning when developers use the keyboardType prop on TextInput in React Native Windows Fabric. This prop is not yet functional due to Windows platform limitations with the Touch Keyboard and windowless RichEdit controls.

What

Added a warning mechanism in WindowsTextInputComponentView.cpp that:

  • Emits a debug message when keyboardType is set to any value other than "default"
  • Uses a static set to ensure each warning is shown only once per app session (not per component)
  • Links to documentation for missing props

Files Changed

  • vnext/Microsoft.ReactNative/Fabric/Composition/TextInput/WindowsTextInputComponentView.cpp

Code Added

namespace {
// Track which prop warnings have been emitted to avoid spamming the developer
static std::unordered_set<std::string> s_emittedPropWarnings;

// Emit a warning once per unique message
void EmitPropWarningOnce(const std::string &warningKey, const std::string &message) {
  if (s_emittedPropWarnings.find(warningKey) == s_emittedPropWarnings.end()) {
    s_emittedPropWarnings.insert(warningKey);
    OutputDebugStringA(("[React Native Windows] " + message + "\n").c_str());
  }
}
} // namespace

And the warning check in updateProps:

// Warn about props that are not yet implemented on Windows
if (!newTextInputProps.keyboardType.empty() && newTextInputProps.keyboardType != "default") {
  EmitPropWarningOnce(
      "TextInput.keyboardType",
      "The keyboardType prop for TextInput is not yet available on React Native Windows Fabric. "
      "See: https://microsoft.github.io/react-native-windows/docs/new-arch-missingProps . "
      "Setting keyboardType=\"" + newTextInputProps.keyboardType +
      "\" will not change the Touch Keyboard layout. "
      "Currently supported value: 'default'");
}

Why

The keyboardType prop is accepted by the TextInput component but has no effect on Windows Fabric. Without this warning, developers may not realize the prop isn't working, leading to confusion when the Touch Keyboard layout doesn't change as expected on iOS/Android.

Technical Background

  • Windows Touch Keyboard uses ITextInputScope to determine keyboard layout
  • The windowless RichEdit control (ITextServices/ITextHost) used in Fabric does not properly communicate InputScope to the Touch Keyboard
  • This is a platform limitation that requires a different approach to solve

How

The warning is implemented using:

  1. std::unordered_set to track emitted warnings (prevents spam)
  2. OutputDebugStringA to output to Visual Studio debug console
  3. Static storage so warnings persist across component instances

When Warning Appears

The warning is shown:

  • Once per app session (not per component mount)
  • When any TextInput with a non-default keyboardType mounts or updates
  • In Visual Studio Output window (Debug pane) or DebugView

Warning Message Example

[React Native Windows] The keyboardType prop for TextInput is not yet available on React Native Windows Fabric. See: https://microsoft.github.io/react-native-windows/docs/new-arch-missingProps . Setting keyboardType="number-pad" will not change the Touch Keyboard layout. Currently supported value: 'default'

Testing

  1. Run playground app with a TextInput that has keyboardType="number-pad"
  2. Check VS Output window (Debug → Windows → Output) for the warning message
  3. Verify warning appears only once even with multiple TextInputs using keyboardType

Test Code

<TextInput
  keyboardType="number-pad"
  placeholder="This will show a warning"
/>
Microsoft Reviewers: Open in CodeFlow

@Nitin-100 Nitin-100 requested a review from a team as a code owner March 16, 2026 03:11
@acoates-ms
Copy link
Contributor

We dont do this for the 10s (100s?) of other properties that do not work on windows. Android/iOS also do not generally warn if you use a platform specific property on those platforms. Ex: using tabIndex on iOS does not cause any kind of warning, it's just silently ignored.

The code also appears to run in production, so it's causing additional work in production apps.

Also, this will cause debug output spam, which apps may want to have more control over. - If every component outputs to debug then it becomes hard to see anything.

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.

2 participants