[Bug]: Severe keyboard `Tab` key navigation failures in data-entry forms (Focus drops, jumps to top, or freezes)

[MosheWelcher]

Is there an existing issue for this?

• I have searched the existing issues

Description

I am trying to build a high-speed, keyboard-only data entry form. However, native Appsmith widgets make this impossible because the browser's focus and keyboard tab order break in three distinct, reproducible ways.

(Note: All references to "Tab" in this report refer to pressing the physical Tab key on a keyboard, not the Appsmith Tabs UI widget).

Without a native focusWidget() JS function or a manual TabIndex property, developers are forced to build custom HTML iframes just to get basic keyboard navigation to work.

Workarounds Attempted:

• Reverse UI Layout: Reversing the physical layout to avoid tabbing out of a Select widget (didn't help - later discovered this issue is for all widgets not only select).
• Custom Widgets: The only working solution currently is to abandon Appsmith's native inputs entirely and write a Custom Widget using raw HTML <input> tags and custom JS event listeners to manually trap and pass focus.

Environment:

• Appsmith Version: 1.96
• OS: Ubuntu
• Browser: Chrome

Steps To Reproduce

Bug 1: The "Select Widget Portal" Focus Drop

1. Place a Select widget and an Input widget side-by-side.
2. Click into the Select widget, type to search, and hit Enter to confirm the selection.
3. Press the Tab key to move to the Input widget.

• Actual Behavior: Because the Select dropdown renders in a portal at the bottom of the DOM, when the portal closes on Enter, the browser completely loses its focus state. Pressing the Tab key causes the focus to rocket back to the very first/topmost widget on the canvas instead of the adjacent Input widget.

Bug 2: The Topmost Widget Tab Key Failure

1. Focus the cursor on the highest widget on the page/canvas.
2. Press the Tab key to move to the next logically placed widget below it.

• Actual Behavior: Nothing happens. The Tab key completely fails to move focus. The only way to escape this state and continue data entry is to manually click into another widget with the mouse, entirely defeating the purpose of keyboard navigation.

Bug 3: The Unpredictable Jump to Top

1. Focus the cursor on a standard Input widget.
2. Type a value and press the Tab key to move to the next widget.

• Actual Behavior: Instead of moving to the adjacent widget, the focus unexpectedly drops and jumps all the way back to the topmost widget on the page. The keyboard tab order completely breaks and resets to the top of the DOM.

Public Sample App

No response

Environment

Production

Severity

High (Blocker to building or releasing)

Issue video log

No response

Version

Self Hosted v.1.96

[linear]

APP-14909

[MosheWelcher]

UPDATE: This might only apply while editing and previewing. I am unsure if it applies for production

[hedgeska]

I’m creating an insurance related app that requires heavy data input. It is imperative that I be able to control the the Tab key for user input

[MosheWelcher]

I’m creating an insurance related app that requires heavy data input. It is imperative that I be able to control the the Tab key for user input

It appears that if you actually commit your changes and push it to production, it works in production