STR:

1. Open this test case:
   data:text/html,<div contenteditable style="width: 10px;">a b<br>c
2. Query the HyperText line offsets at offset 2.
   • Expected: (2, 4, "b\n")
   • Actual: (2, 3, "b")
3. Query the HyperText line offsets at offset 3.
   • Expected: (2, 4, "b\n")
   • Actual: (3, 4, "\n")

This only seems to happen after a line wraps. Line feeds on non-wrapped lines are okay.

This causes the current line to be reported as blank in some rich text editors (including Google Keep) when the user is positioned at the endof the line.

Hmm. I can reproduce this on Gmail just by composing a new message and typing a single letter. However, I can't reproduce that in a simple test case:
data:text/html,<div contenteditable>a<br>
I don't know what's going on here yet.

Aha! I can reproduce it with:
data:text/html,<div contenteditable><br>
then typing a single letter at the beginning. I think the problem here is that we're not updating the line boundaries when they change, so the br thinks it's at the start of a line when it isn't. Fixing bug 1739560 should fix this.

Nope, these are two different bugs.

Previously, we were always comparing with the primary frame of the previous leaf.
If the previous leaf crossed lines, this meant we incorrectly reported that the following leaf started a new line even if it didn't, since the primary frame of the previous leaf was always on a different line.
Now, we use the last continuation (line) of the previous leaf.
This way, if the next leaf continues the final line of the previous leaf, they will have the same line number and so we won't incorrectly report that the next leaf starts a new line.

https://hg.mozilla.org/mozilla-central/rev/e715d1655a82