contenteditable in table cells causes layout issues
OS: Windows 11 · Device: Desktop or Laptop Any · Browser: Firefox 120.0 · Keyboard: US
Open case →Scenario
contenteditable in table cells causes layout issues
When a contenteditable region is inside a table cell (`<td>`), editing the content may cause layout issues in Firefox. The table may resize unexpectedly or the cell may overflow.
other
Scenario ID
scenario-contenteditable-table
Details
When a contenteditable region is inside a table cell (<td>), editing the content may cause layout issues in Firefox. The table may resize unexpectedly or the cell may overflow.
References
- Stack Overflow: Make contenteditable respect initial size of table cell - Table layout issues
- MDN: table-layout - table-layout CSS property
- Stack Overflow: Firefox doesn’t style empty elements - Empty cell behavior
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-0055-contenteditable-in-table-cell | Windows 11 | Desktop or Laptop Any | Firefox 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: contenteditable, firefox
HTML Drag and Drop API with contenteditable
Using the HTML drag-and-drop API inside or alongside contenteditable regions often diverges from behavior on plain elements: default actions, `contenteditable` hit-testing, and `beforeinput`/`drop` ordering differ by browser. Custom editors must reconcile native DnD with their own selection model.
1 case
Tags: contenteditable, firefox
Cursor disappears near contenteditable=false boundaries in Firefox
Firefox may hide or misplace the caret when moving across contenteditable=true/false boundaries—widgets and embeds inside editors are affected.
1 case
Tags: contenteditable, firefox
getTargetRanges() can reference the wrong contenteditable when editors are nested
On some engines (notably Firefox for Android / Fenix), beforeinput getTargetRanges() may describe the outer contenteditable host instead of the inner focused editor. Custom handlers that trust targetRanges alone may delete or insert in the parent surface while the user believes they are typing in a nested field.
1 case
Tags: table, contenteditable
Focus in table cells with contenteditable (legacy IE)
Internet Explorer and old EdgeHTML had specific bugs when focusing contenteditable inside table cells—caret not appearing, wrong active element, or selection stuck in adjacent cells.
1 case
Tags: contenteditable
role="textbox" and screen reader behavior with contenteditable
Assistive technologies map contenteditable to textbox-like semantics when authors use role=textbox or aria-multiline—conflicts with actual HTML semantics and browser AX trees can confuse announcements.
1 case
Comments & Discussion
Have questions, suggestions, or want to share your experience? Join the discussion below.