1648351 - [contenteditable] Right-click to collapse the selection. Right-clicking moves the caret to a different position.

Status: VERIFIED FIXED

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

Description

[Alice0775 White]

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.

Comment 1

[Alice0775 White]

Attachment: sample html

Comment 2

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

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.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 4

[Alice0775 White]

(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.

Comment 5

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

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

Comment 6

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

(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?

Comment 7

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

(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.)

Comment 8

[Alice0775 White]

(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!

Comment 9

[Alice0775 White]

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.

Comment 10

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

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

Comment 11

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

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.

Comment 12

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

The new behavior is, right click (in strictly speaking, at mousedown), caret position is moved except when:

1. You click when selection is not collapsed
2. You click in editable content

However, you can also change #1 with ui.mouse.right_click.collapse_selection.stop_if_non_collapsed_selection pref. Then, right click outside selection collapses to the position except when clicked in the selected content.

Additionally, there is a ui.mouse.right_click.collapse_selection.stop_if_non_editable_node pref. This is set to false by default, but once set this to true, you can stop collapsing selection only when clicked position is not editable, this may be useful if you want to enable the new behavior only for "paste" command.

Therefore, if all text is selected right click in any empty area in the editor does not cause collapsing selection now.

Comment 13

[Alexandru Trif, Desktop QA [:atrif]]

Attachment: 1648351.gif

Reproduced the issue by using Firefox 120.0a1 (2023-10-05) on Windows 10x64 and the attached test case from comment 1. Selecting some text from the contenteditable area and then r-clicking elsewhere in the editor will collapse the selection.
I can no longer see this issue with Firefox 121.0 on Windows 10x64, macOS 12 or Ubuntu 22.1. Selecting some text from the contenteditable area and then r-clicking elsewhere in the editor will no longer collapse the selection.

However, the caret moves when using r-click on random areas is this expected behavior? Attaching a screen recording. Thank you!

Comment 14

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

Current expectation is mentioned in comment 12. So, if selection is collapsed, moving caret is expected. It's same behavior as native widgets on Windows and macOS. Well, on Linux, preserving selection is the default behavior. I'd like to respect native widget behavior by default, but this is pretty change users' expectation who use Linux and another OS if we change the behavior by default. Therefore I'd like to keep current behavior as default even on Linux. There is a problem, there is no pref to align the behavior to Linux. I.e., no pref to make selection preserved when collapsed. Alice-san, do you want a new pref for it?

Comment 15

[Alice0775 White]

I prefer current behavior h Nightly on Windows10 and Linux(Ubuntu22.04).

I.e., no pref to make selection preserved when collapsed

Is this the behavior of gedit?
If so, it might make sense to match that behavior in Linux(Ubuntu22.04).

Comment 16

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

(In reply to Alice0775 White from comment #15)

I.e., no pref to make selection preserved when collapsed

Is this the behavior of gedit?

The "Text editor" and the find field of the default filer of Ubuntu behave so.

If so, it might make sense to match that behavior in Linux(Ubuntu22.04).

Okay, I'll file an enhancement bug and I'll try to fix it when I have spare time.

Comment 17

[Alexandru Trif, Desktop QA [:atrif]]

Thank you very much both! I will close this issue as verified given the above comments.