BR tag deleted when typing after selected line
OS: Windows 7-10 · Device: Desktop Any · Browser: Internet Explorer 11 · Keyboard: Any
Open case →Scenario
In Internet Explorer 11, typing after selecting a line of text in a contenteditable div can unexpectedly delete the BR tag, causing lines to merge.
In Internet Explorer 11, when a line of text is selected in a contenteditable div and the user types, the <br> tag at the end of the line can be unexpectedly deleted, causing lines to merge. This breaks the document structure and formatting.
The issue occurs when:
contenteditable div contains multiple lines separated by <br> tags<br> tag at the end of the selected line is deletedconst editor = document.querySelector('[contenteditable]');
editor.addEventListener('beforeinput', (e) => {
if (e.inputType === 'insertText' || e.inputType === 'insertCompositionText') {
const selection = window.getSelection();
if (selection.rangeCount > 0) {
const range = selection.getRangeAt(0);
// Check if selection includes a BR tag
const container = range.commonAncestorContainer;
const walker = document.createTreeWalker(
container,
NodeFilter.SHOW_ELEMENT,
{
acceptNode: (node) => {
if (node.tagName === 'BR' && range.intersectsNode(node)) {
return NodeFilter.FILTER_ACCEPT;
}
return NodeFilter.FILTER_REJECT;
}
},
false
);
const brNodes = [];
let node;
while (node = walker.nextNode()) {
brNodes.push(node);
}
// Store BR nodes to restore later
if (brNodes.length > 0) {
e.preventDefault();
// Delete selected content
range.deleteContents();
// Insert new text
const textNode = document.createTextNode(e.data || '');
range.insertNode(textNode);
// Restore BR tags after the inserted text
brNodes.forEach(br => {
const newBr = document.createElement('br');
textNode.parentNode.insertBefore(newBr, textNode.nextSibling);
});
// Update selection
range.setStartAfter(textNode);
range.collapse(true);
selection.removeAllRanges();
selection.addRange(range);
}
}
}
});
editor.addEventListener('input', (e) => {
// Normalize BR tags after input
const lines = editor.innerHTML.split('<br>');
const normalized = lines
.map(line => line.trim())
.filter(line => line.length > 0)
.join('<br>');
if (normalized !== editor.innerHTML) {
// Restore BR tags if they were lost
editor.innerHTML = normalized;
}
});
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-0311-ie11-br-tag-loss-en | Windows 7-10 | Desktop Any | Internet Explorer 11 | Any | draft |
Open a case to see the detailed description and its dedicated playground.
OS: Windows 7-10 · Device: Desktop Any · Browser: Internet Explorer 11 · Keyboard: Any
Open case →Other scenarios that share similar tags or category.
Browsers, especially Internet Explorer and legacy Edge, automatically detect URLs, email addresses, and phone numbers in contenteditable elements and convert them to clickable links. This auto-linking behavior can interfere with editing, cause cursor positioning issues, and create unwanted markup.
The behavior of Enter and Shift+Enter keys in contenteditable elements varies across browsers. Enter may create a new paragraph, line break, or div, while Shift+Enter may create a line break or behave differently. The resulting DOM structure also varies.
When creating line breaks in contenteditable elements, browsers use different HTML elements: <br>, <p>, or <div>. This inconsistency makes it difficult to predict and normalize the DOM structure, especially when working with rich text editors.
When typing text next to formatted elements (links, bold, italic, etc.) in contenteditable, the input events may include the formatted element's text in event.data, selection ranges may include the formatted element, and text may be inserted into the formatted element instead of after it. This occurs across different browsers and input methods.
Changing background color (highlighting) in contenteditable elements behaves inconsistently across browsers. Background colors may be applied as inline styles, may not persist when typing, or may interfere with text selection. The behavior differs from text color changes.
Have questions, suggestions, or want to share your experience? Join the discussion below.