Show keyboard on NTP show with native input#8532
Conversation
Command.ShowKeyboard was previously a no-op when the native input field was enabled, so opening the NTP did not bring up the keyboard (it only did for the standard omnibar path). Route the command to showNativeInput() when native input is enabled so the widget attaches and its existing onEnterComplete focuses the input — the same path that already works on manual omnibar tap. Skip when the widget is already attached, since the command can fire multiple times per visit (e.g. CTA refresh) and showNativeInput() tears down and re-animates the widget on each call. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 9044bbc. Configure here.
| // Skip if the widget is already attached — Command.ShowKeyboard can fire | ||
| // multiple times per session (e.g. CTA refresh) and showNativeInput() | ||
| // tears down and re-animates the widget on each call. | ||
| if (binding.rootView.findViewById<View?>(com.duckduckgo.app.browser.R.id.inputModeTopRoot) == null) { |
There was a problem hiding this comment.
Widget-attached check misses bottom omnibar variant
Medium Severity
The guard that prevents redundant showNativeInput() calls only checks for R.id.inputModeTopRoot, but when the omnibar is at the bottom (OmnibarType.SINGLE_BOTTOM), the widget is inflated with R.id.inputModeBottomRoot instead. For bottom-omnibar configurations, this findViewById will always return null even when the widget is already attached, defeating the guard entirely and causing the tear-down + re-animate flicker on every repeated Command.ShowKeyboard fire (e.g., CTA refresh). NativeInputManager.hideNativeInput and removeWidget both correctly check for both IDs — this check needs the same treatment.
Reviewed by Cursor Bugbot for commit 9044bbc. Configure here.


Task/Issue URL: https://app.asana.com/1/137249556945/project/1214157224317277/task/1214282876290070?focus=true
Description
When the native input field user setting is enabled, opening the NTP did not bring the keyboard up. The standard omnibar path worked because
Command.ShowKeyboardcallsshowKeyboard()on the omnibar's text input; the native-input branch of the handler inBrowserTabFragmentwas a no-op.This routes the command to
showNativeInput()when native input is enabled, so the widget attaches and its existingonEnterCompletefocuses the input — the same path that already works on a manual omnibar tap. The handler skips when the widget is already attached, sinceCommand.ShowKeyboardcan fire more than once per visit (e.g. CTA refresh) andshowNativeInput()tears down and re-animates the widget on each call.Steps to test this PR
Native input enabled
Native input disabled (regression check)
UI changes
🤖 Generated with Claude Code
Note
Low Risk
Low risk UI behavior change limited to
Command.ShowKeyboard, now surfacing the native input widget and avoiding repeated re-attach animations when the command fires multiple times.Overview
Fixes NTP keyboard focus when native input is enabled by routing
Command.ShowKeyboardtoshowNativeInput()(only if the widget isn’t already attached) instead of doing nothing.Also includes minor Kotlin formatting/line-wrapping changes and a small command handler spacing tweak.
Reviewed by Cursor Bugbot for commit 9044bbc. Bugbot is set up for automated code reviews on this repo. Configure here.