Add a pref to prevent a right-click when selection is collapsed to move caret
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox122 | --- | wontfix |
| firefox123 | --- | wontfix |
| firefox124 | --- | fixed |
People
(Reporter: BUGMENOT91232, Assigned: masayuki)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0
Steps to reproduce:
(Note, works fine in 120.0, starts this behavior in 121.0 and continues in 121.0.1)
- Copy any text to file clipboad.
- Click on any text box like for this form or address bar (WITHOUT entire address selected, obviously).
- Right-click anywhere else in that box and select paste.
- It'll paste it whereever instead of the already selected position.
It seems to be tied into effectively left-clicking when using the right mouse button to open a context menu. I'm curious if this has anything to do with the copy/paste or touchscreen updates. Probably not, but doesn't hurt to mention.
Actual results:
Cursor moves when using context menu (regression?)
I verified this with different machines that it's specific to 121.0.
Expected results:
Cursor stays where set. This ends up making it more tedious to right-click on edit boxes.
|
||
Comment 2•9 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
I think the bot picked up on the address bar example, but it's just the easiest way to demonstrate it since that text edit box is always available. I'm not even sure if this is a Core issue (XUL? That doesn't look right, either), and I didn't see a mouse-specific component for Firefox to file a bug report on.
It should probably be considered an accessibility issue but a minor one? Older people lose fine control of mouse pointer.
The 2nd computer I tested it on had Server 2019. I have not tested it on any of my Linux or FreeBSD boxes, and I don't even know if it's applicable to Android version of Firefox. It's not like many people use a mouse on their cell phone or tablet PC.
|
||
Updated•9 months ago
|
|
|
||
Comment 5•9 months ago
|
||
:masayuki, since you are the author of the regressor, bug 1845241, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
I Just read 1845241, and realized I might have accidentally stepped into a really complicated problem that seems simple on first sight. Will it cause problems with caret mode trying to fix this? :(
|
Assignee | |
Comment 7•9 months ago
|
||
According to the timing, must be a regression of bug 1864334.
However, I cannot reproduce the reported issue. I tested as:
- Copy some text in this bug
- Click in the address bar
- Select "mozilla.org" in the address bar
- Right click outside the highlighted text
- Click "Paste" menu item in the context menu
Then, the "mozilla.org" is replaced with the text copied at step 1 and selection is collapsed at end of the pasted text.
You said:
Actual results: Cursor moves when using context menu (regression?)
So, my result does not match with what you reported. Do I misunderstand something?
(FYI: The behavior can be customized with ui.mouse.right_click.collapse_selection.stop_if_non_collapsed_selection in about:config.)
|
|
Assignee | |
Comment 8•9 months ago
|
||
Oh, bug 1864334 was fixed in 120 too. So, it shouldn't cause this.
|
|
Assignee | |
Comment 9•9 months ago
|
||
Err, the "fixed" in 120 is caused by backing out the regressor (see bug 1864334 comment 10).
Sorry for the spam.
|
Reporter | |
Comment 11•9 months ago
|
||
Yeah, I didn't see this issue in 119 or 120. Only in 121 and 121.0.1. I'll see if I can get better instructions or a video/screenshots. I'll also try that config option to see if it works as a workaround for now, but those usually go away after a year or two. I did reproduce it on two entirely different machines running two versions of Windows. The second machine, I upgraded on top of a 69 version install I had for testing purposes.
|
|
Reporter | |
Comment 12•9 months ago
|
||
https://files.catbox.moe/ps4fa6.mp4 Not sure if it lets me post this link. If not, will I have to send mail?
|
|
Assignee | |
Comment 13•9 months ago
|
||
Ah, you meant when you collapsed selection. Hmm, that's not consistent with the case when selection is NOT collapsed, however, it's compatible with the other browsers... So, I don't think we should change the behavior by default unless a lot of users complain about the new behavior. However, there should be a pref to take the traditional behavior back.
but those usually go away after a year or two.
Basically, this kind of prefs (i.e., that do not cause complicated issues about compatibility between browsers, both behavior has a lot of fans and the implementation is not big) won't be deleted.
|
|
Assignee | |
Updated•9 months ago
|
|
|
Reporter | |
Comment 14•9 months ago
|
||
Thank you - I'll try setting "ui.mouse.right_click.collapse_selection.stop_if_non_collapsed_selection" to "false" and restart browser. If it works or not, I'll update you. :)
|
|
Assignee | |
Comment 15•9 months ago
|
||
(In reply to Joe from comment #14)
Thank you - I'll try setting "ui.mouse.right_click.collapse_selection.stop_if_non_collapsed_selection" to "false" and restart browser. If it works or not, I'll update you. :)
It does not work for you because it's for the behavior when selection is NOT collapsed.
|
|
Assignee | |
Comment 16•9 months ago
|
||
In bug 1845241, we aligned the behavior of Selection at right click to the
other browsers. That may prevent potential web compat issues, but some users
may want to take it back the traditional behavior.
The patch adds a pref to do it only when caret is in an editable element and
when right click occurs in focused editable element. The reason of limiting
only in editable nodes is, collapsed range in non-editable content is not
visible for users unless enabling the caret browsing mode. Therefore, if we
apply the traditional behavior to non-editable content, we'd have bug reports
with this pref and waste time for investigation in some web apps. However,
in editable content, caret shows users and that helps us to understand what
happened in the reporter's environment. Therefore, I think that this pref is
reasonable for some users.
|
|
Reporter | |
Comment 17•9 months ago
|
||
It's still doing it with that setting changed. It defaults to true and I restarted with it set to false. Is it only available in nightly or something?
I used some 3rd-party tools to get that weird mouse click indicator. Red is left, yellow is right, if I remember right.
:edit:
I just saw the other replies. OK, so no way to fix it?
|
||
Comment 18•9 months ago
|
||
|
|
Assignee | |
Comment 19•9 months ago
|
||
(In reply to Joe from comment #17)
I just saw the other replies. OK, so no way to fix it?
Now, the patch is landed. Starting from 124, ui.mouse.right_click.move_caret.stop_if_in_focused_editable_node pref is available to take the traditional behavior back.
|
|
Reporter | |
Comment 20•9 months ago
|
||
So a caret is name for currently focused text box's cursor? That makes a lot more sense why it's called "Caret browsing" then. If push comes to shove, and someone in the future has this problem again (not just for specific programs), they might try using a program like AutoHotKey/AutoIt or gamer mouse drivers settings to replace Right-Click with Context Menu key. Many OSes have a binding feature for keyboard and mouse events so don't need a 3rd-party tool. Mentioned, in case UI trends towards this in the future.
Thank you for this help, and sorry it caused so much trouble for a seemingly small thing, but it was driving me crazy, doing a lot of text entry with difficulty having to aim the mouse more precisely each time! This made me feel old, haha.
The linked discussion does not mention which specific sites for me to see this bug in action on newer and older versions of FF, but I think it's in a related bug linked to from there... just curious what brought up this change. My laptop doesn't have a context menu key so I checked with a USB keyboard, and that key does NOT behave the new way. This is a confirmed workaround if I use a mouse with a remapped button.
|
||
Comment 21•9 months ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 22•9 months ago
•
|
||
(In reply to Joe from comment #20)
So a caret is name for currently focused text box's cursor?
https://developer.mozilla.org/en-US/docs/Glossary/Caret
The linked discussion does not mention which specific sites for me to see this bug in action on newer and older versions of FF, but I think it's in a related bug linked to from there... just curious what brought up this change. My laptop doesn't have a context menu key so I checked with a USB keyboard, and that key does NOT behave the new way. This is a confirmed workaround if I use a mouse with a remapped button.
There is no concrete scenario which the traditional behavior causes a problem. However, that means incompatible result of Selection object after right click. So, it's potentially risky for compatibility between browsers. Especially when caret is not shown in non-editable text nodes.
Description
•