How to Style Contenteditable in Firefox

contentEditable cursor position/style in FireFox

I waited and used the content editable only in Firefox 4 and higher. I filed this and a few other bugs which the Mozilla team has fixed for FF 4.

Using contentEditable in Firefox: 'bold' renders correctly, but html code is incorrect

Here's a jsFiddle for your original code: http://jsfiddle.net/Bv2Ek/

The issue is that Firefox is adding font-weight: bold to the style attribute of the editable <div> element to make all of it bold, which is quite a reasonable thing to do. If you would rather it used <b> or <strong> elements to apply the boldness, you can use the StyleWithCSS command first. Add the following to your script:

function bold() {
    document.execCommand('StyleWithCSS', false, false);
    document.execCommand('bold', false, null);
}

And your button becomes:

<button onClick="bold(); output.value=input.innerHTML;">Bold</button>

jsFiddle example with amended code: http://jsfiddle.net/Bv2Ek/1/

ContentEditable in Firefox creates 2 newlines instead of 1

This appears to be a bug with Firefox's implementation of innerText.

New lines in contenteditable historically had a lack of consensus on the precise implementation. Gecko inserted <br>s, IE and Opera's Presto wrapped the line in <p> tags, and Webkit and Blink wrapped the line in <div> tags. With its old implementation that used <br> tags, Firefox's innerText worked just fine, exactly how your question wants it to.

However today's modern browsers have reached a general consensus for the sake of consistency. Specifically for Firefox, MDN stated:

As of Firefox 60, Firefox will be updated to wrap the separate lines in <div> elements, matching the behavior of Chrome, modern Opera, Edge, and Safari.

When modern browsers insert an empty new line, they do so by wrapping a <br> in <div> tags. It seems that Firefox's innerText implementation is interpreting this as two new lines.

---

A workaround is quite simple. The execCommand method (unofficial W3 draft but supported by Firefox which is all we need) allows you to manipulate a contenteditable's content with defined commands. One such command is defaultParagraphSeparator, which allows you to specify whether to use <div> or <p> as the container for lines in your contenteditable.

Firefox - and only Firefox - has additionally implemented support for <br>s with defaultParagraphSeparator. With this command the contenteditable behaves like it would have prior to FF60, that is, inserting line breaks instead of wrapping lines within a container.

Thus, all you need to do is put:

document.execCommand("defaultParagraphSeparator", false, "br");

in your JavaScript. All versions of Firefox will then be using <br>s instead of containers for new lines in contenteditable, thus making innerText correctly interpret new lines. And every browser other than Firefox will ignore it.

Firefox contenteditable cursor issue

Here's a fiddle that you might like: http://jsfiddle.net/e5gwc1gq/2/

I believe that the problem is because the :before psuedo element doesn't allow access to the underlying parent-div.

The reason I think so is because if you were to replace before with after, the problem persists, but is flipped, ie, now if you click in the left, it won't work properly.

Note: You might want to add word-wrap: break-word; css rule for .content-editable, since firefox doesn't add this by default, but chrome does.

Problems with contenteditable div in Firefox

Try setting

word-break: break-all;

or

word-break: break-word;

`contenteditable = true` height issue in FireFox

workaround:

[contenteditable='true']:before {
    content: "\feff ";
}

CSS2 section 10.6.3:

The element's height is the distance from its top content edge to the first applicable of the following:

1. the bottom edge of the last line box, if the box establishes a inline formatting context with one or more lines
2. the bottom edge of the bottom (possibly collapsed) margin of its last in-flow child, if the child's bottom margin does not collapse with the element's bottom margin
3. the bottom border edge of the last in-flow child whose top margin doesn't collapse with the element's bottom margin
4. zero, otherwise

For this empty div,

1 through 3 are not applicable, since the div is empty. It has no line boxes or children.
Item 4 therefore applies.

The workaround enforces at least one line box inside the div, so that it gets nonzero height.

---

Related Topics