Right click behavior is different between Contenteditable(incl. designmode) and other input elements.

Steps To Reproduce:

1. Select a text, or put caret somewhere.
2. Right click

Actual results:
Selection will be collapsed.
Caret will move.
If selected whole text, the behavior is as expected even if right-clicking on empty area.

Expected Results:
It should be "Selection should be preserved. Caret should not move.".
Because often the right click position is out of alignment with the last selection or caret position.

Collapsing existing selection and moving the caret is also the behavior in Chrome. Not sure whether it will be web compatible when we remove this behavior. I guess it can be useful to not collapsing existing one, though.

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

(In reply to Kagami [:saschanaz] (they/them) from comment #2)

Collapsing existing selection and moving the caret is also the behavior in Chrome. Not sure whether it will be web compatible when we remove this behavior. I guess it can be useful to not collapsing existing one, though.

Yes.
I dislike Chrome's behavior. Because if the mouse is moved unintentionally after selecting text with the mouse, the selection is often collapsed when subsequently right-clicked. This is undesirable.

It seems that Chrome does not collapse selection if new collapsing candidate position is in current selection range. I think that we should follow this because:

• Collapsing selection with a secondary button click allows users to insert pasting content where they clicked
• Not collapsing selection with a secondary button click near selection range allows users to copy selection easier

(In reply to Alice0775 White from comment #4)

if the mouse is moved unintentionally after selecting text with the mouse, the selection is often collapsed when subsequently right-clicked. This is undesirable.

Oh, do you see that frequently?

(I wonder, making the behavior switchable with a new pref and aligning the behavior to Chrome by default may be safer from web-compat point of view.)

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

(In reply to Alice0775 White from comment #4)

if the mouse is moved unintentionally after selecting text with the mouse, the selection is often collapsed when subsequently right-clicked. This is undesirable.

Oh, do you see that frequently?

Yes.
That's why I use Firefox!

FWIW, On Windows10, notepad.exe, wordpad.exe, hidemaru.exe, notepad + + .exe, 一太郎2021 etc., behave the same way as Firefox's textarea, without collapsing the selection.

Thank you, I think that old folks align such behaviors to native widget as far as possible or native widget on Windows.

There are the cases that:

• in <input> or <textarea>
• in the other editable elements like contenteditable
• in non-editable elements

and each one has 2 conditions, selection is collapsed or not.

I think that if selection is collapsed, we should move caret anyway. However, the others may depend on users' preferences. I can make all of them switchable with prefs. So, anyway, I'll write patches for bug 1845241.