Actions to reproduce
Edit <h1>ab<u>cd</u></h1> in Firefox. Select from 'b' to 'c' inclusive, then press 'x'.

Expected behaviour
DM and DOM agree.

Observed behaviour
'x' is underlined in DOM but not in DM.

Explanation

VE DM uses Chromium-like rules:

1. If the selection is not collapsed, take the annotation of the first (document-earliest) content in the selection.
2. Else if the (collapsed) selection is in an empty block, use no annotations.
3. Else if the (collapsed) selection is at the start of a (non-empty) block, take the annotations of the first content in the block.
4. Else (the collapsed selection is in a non-empty block but not at the start) take the annotations of the content just before the selection.

However this gets out of sync with Firefox contenteditable, which uses a different rule:

• Use the annotations at the focus UNION the annotations at the anchor

I have verified this on data:text/html,<h1 contenteditable>a<i>b</i>c<u>d</u>e</h1> by applying every possible selection, remembering that at an annotation boundary, the Firefox anchor lies on the side of the annotation tag from which it cursored. E.g.:

• Home, right, shift-(right, right, left) selects "<i>b</i>" . Typed text is plain (no annotation).
• Home, right, right, left, shift-(right, right) selects "b</i>c". Typed text is italic.
• BUT Home, right, right, left, shift-(right, right, right, left) selects "b</i>c<u>". Typed text is underlined.

Actually, the rule even applies for annotations at the block start. E.g. On data:text/html,<h1 contenteditable><u>x</u></h1> ,

• Home, shift-end selects "x". Typed text is underlined.
• BUT CTRL+A selects "<u>x</u>". Typed text is plain.

Possible solution

Rather than using one set of rules, or inferring which rules apply, it might make sense to look at what the browser has actually done. This is slightly scary though, because browsers can and do reorder the annotation stack as they please. Working out exactly how far to trust the browser is the key question.