Drag and Drop API behavior differs in contenteditable
OS: macOS 14.0 · Device: Desktop or Laptop MacBook Pro · Browser: Chrome 120.0 · Keyboard: US
Open case →Scenario
Drag and Drop API behavior differs in contenteditable
Drag and Drop API behavior differs in contenteditable
Scenario ID
scenario-drag-drop-api
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-0083-contenteditable-with-drag-drop-api | macOS 14.0 | Desktop or Laptop MacBook Pro | 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: api, chrome
Clipboard API paste does not work in contenteditable
When using the Clipboard API (navigator.clipboard.readText() or navigator.clipboard.read()) to programmatically paste content into a contenteditable region, the paste operation may fail or not work as expected.
2 cases
Tags: chrome, macos
CSS filter may affect contenteditable performance
When a contenteditable element has CSS filters applied (blur, brightness, etc.), editing performance may be degraded. Typing may lag, and selection may be slow to update.
1 case
Tags: chrome, macos
CSS will-change may improve or degrade contenteditable performance
When a contenteditable element has CSS will-change property set, performance may be affected. In some cases, it may improve performance by hinting the browser about upcoming changes. In other cases, it may degrade performance by creating unnecessary layers.
1 case
Tags: drag-drop, macos
File API drag and drop does not work in contenteditable
When trying to drag and drop files into a contenteditable element, the File API may not work as expected. File drop events may not fire, or file content may not be accessible.
1 case
Tags: chrome, macos
Virtual scrolling libraries interfere with contenteditable selection
When a contenteditable element is used with virtual scrolling libraries (e.g., for large documents), the virtual scrolling mechanism may interfere with text selection and caret positioning. The selection may be lost when elements are removed from the DOM during scrolling.
1 case
Comments & Discussion
Have questions, suggestions, or want to share your experience? Join the discussion below.