Firefox 115 broke "New tab next to current tab" middle mouse click functionality of the new tab button
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox-esr115 | --- | wontfix |
firefox115 | --- | wontfix |
firefox116 | --- | wontfix |
firefox117 | --- | wontfix |
People
(Reporter: allo, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Firefox opened a new tab next to the current tab when clicking the new tab button with the middle button of the mouse.
Now it opens the URL in the clipboard in a new tab, effectively breaking the function to open a new tab next to the current one. The added functionality is already available from the URL bar via the "paste and go" function, so it doesn't have to be added to the new tab button and remove a useful existing function.
You can revert this new behavior by going to about:config
and changing browser.tabs.searchclipboardfor.middleclick
to false
. You can also make new tabs open adjacent to the current tab without having to middle-click by changing browser.tabs.insertAfterCurrent
to true
.
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1418462
:brice.laurencin, since you are the author of the regressor, bug 1418462, could you take a look?
For more information, please visit BugBot documentation.
Thanks for the setting, I really hope it won't get deprecated in the future.
I do not want to modify the default behavior, because I only sometimes need the inverted behavior and it is useful to be able to add tabs next to the current tab or to the end of the tab bar depending on what you're currently doing.
Sorry, it looks like my comment at the same time with your changes removed the tracking flags. I don't think I can set them myself, so you need to add them again.
Comment 5•2 years ago
|
||
Set release status flags based on info from the regressing bug 1418462
Comment 6•2 years ago
|
||
(In reply to Kestrel from comment #1)
You can revert this new behavior by going to
about:config
and changingbrowser.tabs.searchclipboardfor.middleclick
tofalse
. You can also make new tabs open adjacent to the current tab without having to middle-click by changingbrowser.tabs.insertAfterCurrent
totrue
.
Sounds like this should solve the problem for the reporter, and the behavior change was otherwise intentional. Closing this bug.
It worksforme, but I think it follows no common Linux UI guideline.
The common pattern would be pasting onto the tab bar or, as already exists, use paste&go in the context menu of the URL bar. Correct me when I'm wrong, but I do not know any other Linux program that uses "paste on new-tab button" for opening something from the clipboard. On the other hand, UI elements like the icons-only-taskbar in plasma use middle click for "new instance".
By the way: I didn't test it as I have configured klipper to synchronize clipboards, but does it at least use the correct clipboard (i.e. selected text clipboard) or does it use the "ctrl-c clipboard"? That's another Linux/X11 subtlety that may cause confusion when pasting with the middle mouse button may paste something else than middle clicking the button may open.
Updated•2 years ago
|
Description
•