(Firefox) Misplaced caret when selecting a RichText element

[mcsf]

Describe the bug

Caret is erroneously positioned at the start of a RichText element when selecting a block in Firefox.

To Reproduce

Steps to reproduce the behavior:

1. Start with a post (I'm using a sizable post provided here).
2. Make sure no blocks are selected.
3. Click on the end of a textful RichText element, or click in the middle of the text.
4. Observed: Caret is positioned at the start of the element.

Expected behavior

Caret should be placed where I clicked.

Screenshots

Desktop (please complete the following information):

• OS: macOS
• Browser: Firefox Developer Edition

[oandregal]

I can repro this in Ubuntu Linux, Firefox 63.

It looks like this happens only the first time a block is selected. If I repeat the steps outlined by @mcsf the caret ends up in the proper position the second and subsequent times.

[oandregal]

In my testing, step 2 above (making sure no block is selected) isn't necessary, I can always repro this bug the first time a block is selected.

[oandregal]

This is what I know so far. When this bug is reproduced:

• createRecord returns 0 as the start and end positions.
• window.getSelection() returns 0 as its anchorOfftset and focusOffset. Accordingly, getAnchorAt( 0 ) returns also 0 for startOffset and endOffset.

The offset values for selection/range are properly set when the behavior is correct.

Checked MDN and canisue for compatibility issues but didn't find any.

[mcsf]

@nosolosw, thanks for testing. I haven't checked, but did #11965 help at all?

[oandregal]

No, it hasn't solved this.

[oandregal]

I'm struggling to find a minimal reproducible case to report to bugzilla.

Searching in the database I've found this one: getSelection() returns wrong anchorNode/anchorOffset when selection contains nested different contenteditable context. It points to this jsfiddle to play with the testcase. Sharing in case it sparks any thoughts.

[ellatrix]

I can look into this issue, but it seems slightly less pressing atm?

[mcsf]

I'm sure other issues are more pressing, but this one is nevertheless a pretty bad experience.

[mcsf]

Since this is a browser issue and we need to really focus on our priorities, punting to Follow-Ups.

[danielbachhuber]

I've run into this issue too on the latest master. Here's a GIF of my experience:

[mcsf]

Just for the record, I can still repro this, but I've also noticed that the caret only gets misplaced (at the beginning of the element) if that RichText element has never been focused before. Once a RichText element A has been focused, then placing the caret in some other field/block, then placing it back on A will result in the caret being properly placed.