User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160328182534 Steps to reproduce: Open Firefox 46 in a fresh profile Go to any website (for example www.firefox.com) copy the link from awesome bar. now open a new tab or go to any other website in other tab. click any other place to remove focus from the awesome bar click the mid button of your mouse. Actual results: the link is automatically pasted and the tab is opening the website of copied link (in this case firefox.com) Expected results: the link should not pasted and does not go to the copied url
3 years ago
Component: Untriaged → Location Bar
Middle click to copy doesn't work in Windows, what's its equivalent on Windows? (to try to reproduce it if it's not specific to Linux)
I don't have windows machine in my home, sorry :(
I can confirm this issue on Firefox 46 Beta 7 on Ubuntu 13.10 32bit.
Reproduced on both current stable and nightly. This is troublesome and can cause some lack of understanding for some users. Does this by the way really belong to location bar component as the trigger is a middle click on a webpage?
I don't know, but people familiar with the location bar could investigate the issue.
We're not going to fix this in 46 or 47. This is likely too minor to track for 48 but setting the status flag so that this can go through triage.
This is filed as a 46 regression, but it seems we don't know when exactly it regressed or what bug was responsible?
Alice, could you find a regression range on Linux with STR in comment #0, please?
AFAIK, I think this is a default(intentional) behavior on Linux. (If you do not want to the default behavior, you should toggle middlemouse.contentLoadURL in about:config.)
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 366945
Karl (see comment 9) -- is this a regression we should fix?
3 years ago
(In reply to David Bolter [:davidb] from comment #11) > Karl (see comment 9) -- is this a regression we should fix? Not a regression. I don't see a good reason to change the behavior, but if there were, then we'd need another way to quickly open urls from the primary selection. The logical candidate would be the tab title, but the bug report (don't recall the number) for providing such behavior there has been marked wontfix. wontfix is the correct resolution for bug 366945 in the absence of an alternative.
You need to log in before you can comment on or make changes to this bug.