Fullscreen API may affect contenteditable focus and selection
OS: Windows 11 · Device: Desktop or Laptop Any · Browser: Chrome 120.0 · Keyboard: US
Open case →Scenario
Fullscreen API may affect contenteditable focus and selection
When a contenteditable element enters or exits fullscreen mode using the Fullscreen API, focus and selection may be lost. The caret position may reset, and editing may be disrupted.
focus
Scenario ID
scenario-fullscreen-api
Details
When a contenteditable element enters or exits fullscreen mode using the Fullscreen API, focus and selection may be lost. The caret position may reset, and editing may be disrupted.
References
- MDN: Fullscreen API Guide - Fullscreen API documentation
- MDN: contenteditable global attribute - contenteditable documentation
- Stack Overflow: contenteditable loses selection when another input focuses - Selection preservation techniques
- ProseMirror Discuss: Selection is lost on Safari when editor is blurred - Safari selection issues
Scenario flow
Visual view of how this scenario connects to its concrete cases and environments. Nodes can be dragged and clicked.
Variants
Each row is a concrete case for this scenario, with a dedicated document and playground.
| Case | OS | Device | Browser | Keyboard | Status |
|---|---|---|---|---|---|
| ce-0086-contenteditable-with-fullscreen-api | Windows 11 | Desktop or Laptop Any | Chrome 120.0 | US | draft |
Cases
Open a case to see the detailed description and its dedicated playground.
Related Scenarios
Other scenarios that share similar tags or category.
Tags: focus, chrome, windows
autofocus attribute does not work on contenteditable
The autofocus attribute, which automatically focuses form inputs on page load, does not work on contenteditable elements. There is no built-in way to automatically focus a contenteditable region when a page loads.
1 case
Tags: focus, chrome
WebKit contenteditable Focus Bug
A known bug in WebKit browsers prevents focus from transferring correctly from contenteditable elements to non-editable elements. A workaround involves using a hidden input field to manage focus transitions.
1 case
Tags: focus
Focus is lost when clicking on certain elements within contenteditable
When a contenteditable region contains interactive elements (buttons, links, etc.), clicking on these elements causes the contenteditable to lose focus. This interrupts the editing flow and may cause the caret to disappear.
1 case
Tags: focus
Programmatic focus selects all content
In Chrome and Safari, calling focus() on a contenteditable div can select the entire content instead of placing the cursor at the beginning, as observed in Firefox and IE.
1 case
Tags: focus
Nested contenteditable elements cause focus and selection issues
When a contenteditable element contains another contenteditable element, focus behavior becomes unpredictable. Clicking on the nested element may not properly focus it, and selection ranges may span across both elements incorrectly.
1 case
Comments & Discussion
Have questions, suggestions, or want to share your experience? Join the discussion below.