Links are pasting in awesome bar by middle click without focusing

RESOLVED DUPLICATE of bug 366945

Status

()

defect
P4
normal
RESOLVED DUPLICATE of bug 366945
3 years ago
2 years ago

People

(Reporter: 63raihan, Unassigned)

Tracking

({regression, regressionwindow-wanted})

46 Branch
Unspecified
Linux
Points:
---

Firefox Tracking Flags

(firefox46 wontfix, firefox47 wontfix, firefox48 wontfix, firefox49 wontfix, firefox50 wontfix)

Details

(Whiteboard: [fxsearch])

(Reporter)

Description

3 years ago
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

Comment 1

3 years ago
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)
(Reporter)

Comment 2

3 years ago
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

Comment 4

3 years ago
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.

Updated

3 years ago
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?

Updated

3 years ago
OS: Unspecified → Linux

Comment 8

3 years ago
Alice, could you find a regression range on Linux with STR in comment #0, please?
Flags: needinfo?(alice0775)

Comment 9

3 years ago
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)

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 366945
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)
Too late to fix in 50.1.0 release
You need to log in before you can comment on or make changes to this bug.