1593327 - Firefox maintains cursor position on contenteditable after right-clicks elsewhere, so users can believe they are still editing when they are not.

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect, P2)

Description

[Thomas Wisniewski [:twisniewski]]

Attachment: testcase.html

See the attached testcase. In Chrome, the selection anchor is lost upon right-clicking, so no text is selected. Where in Firefox the anchor remains, and the user sees a selection that seems like it should still function to edit the contenteditable text, when it does not. Note that I'm not certain if this is Linux-specific behavior, as I've only tested on Linux at the moment.

Edit: actually, I missed his comment originally, but in the related webcompat bug, Masayuki says this is related to bug 1318312:

When changing Selection with user's key operation without focus but in an editable element should set focus, but we don't

Comment 1

[John Dai[:jdai]]

(In reply to Thomas Wisniewski [:twisniewski] from comment #0)

Created attachment 9105848 [details]
testcase.html

See the attached testcase. In Chrome, the selection anchor is lost upon right-clicking, so no text is selected. Where in Firefox the anchor remains, and the user sees a selection that seems like it should still function to edit the contenteditable text, when it does not. Note that I'm not certain if this is Linux-specific behavior, as I've only tested on Linux at the moment.

I confirmed that it happened at Linux, MacOS, and Windows for Firefox Nightly 72.0a1.

Edit: actually, I missed his comment originally, but in the related webcompat bug, Masayuki says this is related to bug 1318312:

When changing Selection with user's key operation without focus but in an editable element should set focus, but we don't

Hi Masayuki,
Per description, could you help to confirm this is related to bug 1318312? Thank you.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Yeah, when context menu is closed and selection is still in contenteditable element, focus should've been restored. Or, like Chrome, we should move focus from the editor and do Selection.removeAllRanges() or something to reset Selection. Perhaps, the latter is better because even with current our code, arrow keys are handled with the documentElement to scroll it. So, for compatibility with the other browsers, completely moving focus from the editor must be safer.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

Chrome does not only remove the existing selection, it also moves the (invisible) caret to the right-clicked node. This is exactly what Gecko does when the right click happens inside contenteditable, so maybe this behavior should extend to the whole DOM tree.

FYI, there is a counter issue (Bug 1648351) that prefers not to do this.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Now, Gecko moves caret to the collapsed selection in this case by default. I'm not sure whether the old behavior is useful, but you can restore the old behavior with changing ui.mouse.right_click.collapse_selection.stop_if_non_editable_node pref to true.