[Vega OS] Native virtual keyboard fails to open automatically on focus for HTML input elements on physical hardware

Vega Open Beta Bug Reports
,
1

1. Summary

On a physical Vega OS device, when navigating to a web page where spatial focus is automatically set on an HTML tag, the native virtual keyboard fails to open automatically. Moving focus programmatically to the input element highlights the field, but com.amazon.inputmethod.service is not invoked until the user explicitly presses the Select / Enter button on the hardware remote control.

App Name: CRAVE
App Link on Amazon Appstore: In Development
Bug Severity: Blocks current development

2. Steps to Reproduce

  1. Launch a web application on physical Vega hardware using @amazon-devices/webview.
  2. Navigate to a search page where spatial navigation automatically sets focus onto an HTML element upon load.
  3. Observe that spatial focus lands on the input field, but the native virtual keyboard does not launch automatically.
  4. Press the D-Pad Select / Enter button on the physical remote while focused on the input.
  5. Observe that the native virtual keyboard now opens.

3. Observed Behavior

On physical hardware, when focus lands on the HTML input tag during page load, the element receives spatial focus, but com.amazon.inputmethod.service remains dormant. Programmatic .focus() and synthesized JS events fail to open the native IME. The keyboard remains hidden until a physical Select / Enter keydown event is received from the hardware remote.

4. Expected Behavior

The native virtual keyboard should open automatically as soon as the input field receives focus upon opening the page, without requiring a physical D-Pad remote button press.

4.a Possible Root Cause & Temporary Workaround

Root Cause: Physical Vega OS hardware enforces a strict user-intent security policy that prevents standard DOM .focus() events from opening the system IME service on page load unless directly preceded by a physical remote keypress.

Workarounds Tried:

  • Added com.amazon.inputmethod.service to manifest.toml.
  • Triggered programmatic element.focus() and dispatched synthesized MouseEvent / PointerEvent listeners upon focus land.
  • Added delay timers (setTimeout) after page mount before setting focus.
  • Executed native Vega bridge calls/messages (window.VegaBridge, custom bridge interfaces) to programmatically request the IME input service on focus.
    None of these worked on physical hardware.

5. Logs or crash report

NA

6. Environment

SDK Version: v0.24
React Native Version: NA (Pure Web App)
App State: Foreground
OS Information: NA

7. Example Code Snippet / Screenshots / Screengrabs

[wants]
[[wants.service]]
id = "com.amazon.inputmethod.service"

<WebView  
  hasTVPreferredFocus={true}
/>


<input
  id="search-input" 
  type="text" 
  autofocus 
  tabindex="0" 
/>

if (window.VegaBridge && typeof window.VegaBridge.postMessage === 'function') {
window.VegaBridge.postMessage(JSON.stringify({ action: 'SHOW_KEYBOARD' }));
}

:backhand_index_pointing_right: Playback Issues

NA

:backhand_index_pointing_right: Additional Context

  • This is a pure web application (hosted via Node.js/HTML/JS) running inside the @amazon-devices/webview container on Vega OS without React Native components.
  • Because the app relies entirely on automatic focus land when navigating to the search/input view, requiring a second explicit remote D-Pad “Select” press breaks the expected 1-click search user experience.
  • We would appreciate confirmation on whether physical Vega OS hardware enforces a hard security policy blocking programmatic DOM .focus() from invoking com.amazon.inputmethod.service, or if there is a recommended web/JavaScript event or bridge call to programmatically trigger the virtual keyboard on physical devices.
3

Hi @html_dev

Welcome to the Amazon Developer Community!!

What we can confirm:

  • Your manifest wiring is correct - [[wants.service]] com.amazon.inputmethod.service is the documented way to enable the on-screen keyboard, and you have it.
  • There is no documented programmatic/JavaScript API to force the native keyboard open on Vega WebView. The documented model is that the keyboard appears when the input is engaged, and the supported web→native bridge is window.ReactNativeWebView.postMessage (handled by the WebView’s onMessage prop) - window.VegaBridge / a SHOW_KEYBOARD action isn’t a real Vega API, so that attempt wouldn’t have had any effect.
  • We’re looking into this with our WebView team. Initial investigation on our side hasn’t found a way to auto-open the keyboard on focus-at-load either, which is consistent with your findings - but we’re still confirming whether this is intended behavior or a gap before giving you a definitive answer.

Known workaround:
Make your initial/entry screen a small React Native view with a TextInput, capture the search text there, and pass it into the WebView over the bridge when you load the first web page - rather than relying on the web input to auto-open the keyboard on load. It has trade-offs (a thin RN shell over your web app), but it preserves a single-entry search flow without the extra remote press.

What we’re still confirming:
Whether the “doesn’t auto-open on focus-at-load” behavior is an intentional user-intent policy or a gap to be addressed, and whether a more direct trigger will be offered for web apps. We’re tracking it internally and will update this thread with the verdict.

Warm Regards,
Ivy

5

Thank you @Ivy for the detailed update and confirmation!

Since our app is structured purely as a web application (Node.js/HTML/JS) without a React Native shell, introducing an RN view wrapper would require a major architectural change.

For context, we also tried sending the postMessage call on focus land from our web code:

TypeScript

(window as FireTVWindow).ReactNativeWebView?.postMessage(
  JSON.stringify({ type: 'vegaOS.showInput' })
);

However, we are not able to trigger the keyboard with the onMessage prop in the webview.

We will monitor this thread closely for the WebView team’s verdict on whether this behavior is an intended security policy or a gap that will receive a direct web/JavaScript trigger in a future SDK update.

6

Thanks @html_dev and understood on the architecture constraint; a full RN wrapper is a big change.

One clarification on the postMessage attempt: ReactNativeWebView.postMessage(…) only delivers a string to the WebView’s onMessage handler on the RN side - it doesn’t itself open the keyboard, and there’s no built-in showInput/SHOW_KEYBOARD action it maps to. So even with the correct bridge, the message would just arrive at onMessage; the native IME wouldn’t open unless there were a supported native call to trigger it. So no message string will make this work today from pure web code.

We’ll post the WebView team’s verdict here as soon as we have it. Thanks for your patience.

Warm regards,
Ivy

7

Hi @Ivy,

Just following up to see if there are any updates from the WebView engineering team regarding whether this behavior is confirmed as an intentional platform design policy or an SDK gap.

We are currently finalizing our app’s search flow design and ticket triage, so having their final verdict would help us officially close out our internal tracking.

Thanks again for your assistance!

8

Hi @html_dev

On physical Vega OS hardware, when a web app (using @amazon-devices/webview) sets spatial focus on an HTML <input> element during page load, the input gets highlighted but the native virtual keyboard (VK) does not open automatically.
The keyboard only appears after the user physically presses the D-Pad Select / Enter button on the remote.

Programmatic .focus(), synthesized JS events, setTimeout delays, and custom bridge calls (window. VegaBridge SHOW_KEYBOARD) all failed to trigger the IME. This breaks the app’s expected 1-click search flow since it relies on auto-focus opening the keyboard.

Amazon Webview Team’s Assessment (why this happens)

The team’s insight is that this is expected behavior, not a defect:

  • Just focusing an element does not bring up the keyboard. On spatial-focus devices (TV), focus only highlights the element. Other platforms (e.g., Android TV) behave the same way.
  • On FireTV CX (FOS and Vega), the VK is designed to open on a button press, not on focus, focusing the input alone won’t open the VK.
  • Rationale: the VK covers the whole screen. Auto-opening it on focus would make it unclear which input field the customer actually has focused. So a deliberate Select/Enter press is required.
  • There is no documented programmatic/JS API to force the keyboard open on Vega WebView, and window.VegaBridge/SHOW_KEYBOARD is not a real Vega API. The supported bridge is window.ReactNativeWebView.postMessage.)

Suggested Steps / Workarounds from the team

  1. Programmatically request focus + simulate a D-Pad center event. During page load, request focus of the input element, then click or synthesize a DPAD center (Select/Enter) event to trigger the VK. Note: user-gesture policy may still block this, but it’s worth trying.
  2. Use a thin RN entry screen (from the forum thread). Make the initial/entry screen a small React Native view with a TextInput, capture the search text there, and pass it into the WebView over the bridge - preserving single-entry search without the extra remote press. Trade-off: adds a thin RN shell over the web app.

The behavior is working as intended (a deliberate user-intent design decision on FireTV CX/Vega), rather than a bug. The recommended path is to work with the button-press model, either simulate the Select event on load (subject to gesture policy) or route initial input capture through a lightweight RN TextInput.

Hope this helps!
Warm Regards,
Ivy