On-screen keyboard does not appear when focusing contenteditable on mobile
OS: iOS Any · Device: Mobile Any · Browser: Safari Latest · Keyboard: US
Open case →Scenario
On some mobile browsers, focusing a contenteditable programmatically or from a non-gesture path may not raise the virtual keyboard—users cannot type until they tap again.
On some mobile browsers, focusing a contenteditable programmatically or from a non-gesture path may not raise the virtual keyboard—users cannot type until they tap again.
Visual view of how this scenario connects to its concrete cases and environments. Nodes can be dragged and clicked.
Each row is a concrete case for this scenario, with a dedicated document and playground.
| Case | OS | Device | Browser | Keyboard | Status |
|---|---|---|---|---|---|
| ce-0552-mobile-keyboard-not-appearing | iOS Any | Mobile Any | Safari Latest | US | draft |
Open a case to see the detailed description and its dedicated playground.
OS: iOS Any · Device: Mobile Any · Browser: Safari Latest · Keyboard: US
Open case →Other scenarios that share similar tags or category.
Mobile browsers may scroll the page to bring the focused field into view when the virtual keyboard opens—sometimes overscrolling or hiding fixed UI and the caret.
The visual viewport shrinks when the keyboard appears; fixed toolbars, sticky UI, and caret visibility interact with resize and scroll events differently than desktop.
After the user or the page scrolls while editing in iOS Safari, the caret may render in the wrong place, disappear until the next tap, or sit outside the visible viewport—especially with fixed headers or virtual keyboard resize.
Managing browser UI collisions, virtual keyboard resizing, and IME candidate window positioning.
Automatic scroll-to-caret may fail when the editable is inside nested scrollers, overflow hidden ancestors, or during rapid input—the user loses sight of the insertion point without manual scroll.
Have questions, suggestions, or want to share your experience? Join the discussion below.