Add runtime warning for unsupported keyboardType

[Nitin-100]

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

[acoates-ms]

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.

[Nitin-100]

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.

Thanks, I have explained the PM team as they were asking for it.