User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

Example HTML:

<div contenteditable="true" id="editor">
  Hello!
  <span id="span"></span>
  <br id="br"></br>
</div>
<button id="button-for-br" type="button">
  document.execCommand('insertText') on br
</button>
<button id="button-for-span" type="button">
  document.execCommand('insertText') on span
</button>

Example JS:

const editor = document.getElementById("editor");
const br = document.getElementById("br");
const span = document.getElementById("span");
const buttonForBr = document.getElementById("button-for-br");
const buttonForSpan = document.getElementById("button-for-span");

buttonForBr.addEventListener("click", () => {
  const selection = document.getSelection();
  selection.removeAllRanges();
  const range = document.createRange();
  range.setStart(br.previousSibling, 0);
  range.setEnd(br, 0);
  selection.addRange(range);
  document.execCommand("insertText", false, "World!");
});

buttonForSpan.addEventListener("click", () => {
  const selection = document.getSelection();
  selection.removeAllRanges();
  const range = document.createRange();
  range.setStart(span, 0);
  range.setEnd(span, 0);
  selection.addRange(range);
  document.execCommand("insertText", false, "World!");
});

Actual results:

• Clicking on the "document.execCommand('insertText') on br" button does not work.
• Clicking on the "document.execCommand('insertText') on span" button works.

Expected results:

• Clicking on the "document.execCommand('insertText') on br" button should work.
• Clicking on the "document.execCommand('insertText') on span" button should work.

There's an error in the example JS provided in the description. I cannot edit the description. Here's the corrected example JS:

const editor = document.getElementById("editor");
const br = document.getElementById("br");
const span = document.getElementById("span");
const buttonForBr = document.getElementById("button-for-br");
const buttonForSpan = document.getElementById("button-for-span");

buttonForBr.addEventListener("click", () => {
  const selection = document.getSelection();
  selection.removeAllRanges();
  const range = document.createRange();
  range.setStart(br, 0); // ONLY THIS LINE CHANGED
  range.setEnd(br, 0);
  selection.addRange(range);
  document.execCommand("insertText", false, "World!");
});

buttonForSpan.addEventListener("click", () => {
  const selection = document.getSelection();
  selection.removeAllRanges();
  const range = document.createRange();
  range.setStart(span, 0);
  range.setEnd(span, 0);
  selection.addRange(range);
  document.execCommand("insertText", false, "World!");
});

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Only fixing the bug described by the summary is simple, but as the testcase, when <br> element follows invisible white-space only text nodes and/or empty inline elements like <span>, the behavior of Blink and WebKit is odd. They put text to the last visible text node, i.e., before the <span> in the testcase. But if I fix this with a simple patch, Gecko puts text immediately before the <br>. Emulating the other browsers' behavior reqires complicated patch, so, I'd like to put it off later.

Reporter: Will you have any problems if I don't fix the insertion position difference here?

In most cases, it's called with selection range which is collapsed in a text
node, but otherwise, the selection may be in an element which cannot have
text nodes. Therefore, before handling the insertion, it should look for
ancestor element which can have text nodes.

Note that this patch makes inserting text immediately before an inclusive
ancestor element whose parent can have a text node. However, both Blink and
WebKit ignores if there are invisible/empty inline nodes. So, even with
this patch, Gecko keeps failing in some tests of the WPT. It should be handled
in a follow up bug because doing it requires complicated code.

Depends on D119064

Reporter: Will you have any problems if I don't fix the insertion position difference here?

Hey Masayuki,

Thanks for taking care of this issue.

Were you able to overcome the issue with the position difference?

https://hg.mozilla.org/mozilla-central/rev/65e999c55652
https://hg.mozilla.org/mozilla-central/rev/6eb77c24726a

(In reply to luiscrisf from comment #8)

Reporter: Will you have any problems if I don't fix the insertion position difference here?

Hey Masayuki,

Thanks for taking care of this issue.

Were you able to overcome the issue with the position difference?

No, doing it requires big patches which affect all inserting edit commands' behavior. In other words, it requires design change of our editor. For web-compat, we should do it in the future, but if it's not so important, we'd like to put it off.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #10)

(In reply to luiscrisf from comment #8)

Reporter: Will you have any problems if I don't fix the insertion position difference here?

Hey Masayuki,

Thanks for taking care of this issue.

Were you able to overcome the issue with the position difference?

No, doing it requires big patches which affect all inserting edit commands' behavior. In other words, it requires design change of our editor. For web-compat, we should do it in the future, but if it's not so important, we'd like to put it off.

I understand. That's fine.

How can I track when the corresponding fix will be released in new versions of Firefox?

(In reply to luiscrisf from comment #13)

How can I track when the corresponding fix will be released in new versions of Firefox?

I'll be contained in 91 as "Milestone" and "Tracking Flags" fields in this bug show. If it'd be backed out from 91, "firefox91" would be set to "wontfix".