User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

open the attached file and right click on the child div

Actual results:

the caret is moved at the start of the contenteditable element

Expected results:

the caret should be moved where the click happens, like when you use left click

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

#1 regression:

Good build: A caret appears at the right mouse click position.
Bad build: The caret is not shown.
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=06b2977afb85&tochange=569a45bfb71c

Suspect of #1 regression: ab8c0ebe600b7687cba76d7c2a429772ac9c0830 Graeme McCutcheon — Bug 682338 - Focus context menu's target on platforms where the context menu is shown on mousedown, not where it's shown on mouseup. r=enndeakin

#2 regression

The build from ae1dfa192faf: The caret is not shown as same as the above bad build.
Bad build: The caret is shown at the contenteditable element.
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ae1dfa192faf&tochange=92c87e95915e

Suspect of #2 regression: 030d8d4684982327356a377cbb13c82b665ce992 Masayuki Nakano — Bug 1083629 Use nsHTMLEditor::IsAcceptableInputEvent() instead of nsEditor::IsDescendantOfEditorRoot() for checking if a mouse down event target is in focused HTML editor r=ehsan

Other browsers seem to select the word that the user clicks on.

Well, it seems that the patch was written with wrong assumption.

On the other hand, I'm not sure that it's right behavior that caret is not moved with a right click in caret browsing mode. There is no handler for it, that was what I didn't expect.

Hmm, there was a request for making the old (and expected by the reporter here) behavior cancelable.

Oh, and the old behavior may be triggered in unexpected cases too.

It seems that we can fix this with touching nsIFrame::HandleEvent. Taking a look...

The patch will change Selection result so I don't think we should/can fix this in ESR branches.

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

FYI: Safari works similar to Chrome, but select a word under the cursor.

Hello,
just to be sure did you switch it to wontfix because you reschedule the fix?

I'm asking because with the current behvaior is not possible to understand where the user has clicked.
So in some cases is not possible to align the browsers behviors when you work on an WYSIWYG editor like TinyMCE

(In reply to pomili.lorenzo85 from comment #11)

Hello,
just to be sure did you switch it to wontfix because you reschedule the fix?
Hi, the bug is not resolved as wontfix. The current release and upcoming release is set to wontfix since we don't have a patch.
The bug is in the team's backlog.

ok, thanks for the clarification :)