Closed Bug 1261551 Opened 8 years ago Closed 8 years ago

Links are pasting in awesome bar by middle click without focusing

Categories

(Firefox :: Address Bar, defect, P4)

46 Branch
Unspecified
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 366945
Tracking Status
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- wontfix
firefox49 --- wontfix
firefox50 --- wontfix

People

(Reporter: 63raihan, Unassigned)

Details

(Keywords: regression, regressionwindow-wanted, Whiteboard: [fxsearch])

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
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)
Flags: needinfo?(63raihan)
I don't have windows machine in my home, sorry :(
Flags: needinfo?(63raihan)
I can confirm this issue on Firefox 46 Beta 7 on Ubuntu 13.10 32bit.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Flags: needinfo?(kohei.yoshino)
Keywords: regression
I don't know, but people familiar with the location bar could investigate the issue.
Flags: needinfo?(kohei.yoshino)
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.
Priority: -- → P4
Whiteboard: [fxsearch]
This is filed as a 46 regression, but it seems we don't know when exactly it regressed or what bug was responsible?
OS: Unspecified → Linux
Alice, could you find a regression range on Linux with STR in comment #0, please?
Flags: needinfo?(alice0775)
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.)
Flags: needinfo?(alice0775)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Karl (see comment 9) -- is this a regression we should fix?
Flags: needinfo?(karlt)
(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.
Flags: needinfo?(karlt)
You need to log in before you can comment on or make changes to this bug.