667340 - The behavior for loading URLs from the clipboard with middle click is inconsistent

Status: NEW

(Firefox :: General, defect)

Description

[Amar Takhar]

User-Agent:       Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20100101 Firefox/5.0
Build Identifier: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20100101 Firefox/5.0

Previous to http://hg.mozilla.org/mozilla-central/rev/4a9b09ae01a7 being committed middle click to load a URL from the clipboard contents worked very well.

This was changed due to bug #414345.  As noted this has been a feature since Firefox 1.5.

I believe it should be fixed in a way that maintains the previous functionality while resolving the issues brought up in #414345.

Completely removing this well-used feature -- at least by myself and many, many others as I attempted to find a fix -- is an unfortunate way to resolve it being too liberal in what it accepts.

Reproducible: Always

Steps to Reproduce:
1. Copy www.mozilla.org into your clipboard and middle click.
2. Copy /path/to/somewhere/ and try middle clicking.

Actual Results:  
1. Nothing
2. Nothing

Expected Results:  
1. Seeing http://www.mozilla.org/
2. Browsing /path/to/somewhere

These work if you prefix http:// and file:// respectivly.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Attachment: maybe something like this?

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Er, with the obvious s/uri/fixupURI/ of course.

Comment 3

[Amar Takhar]

With your patch nothing happens all input is no good even valid URIs.  I did the s/uri/fixupURI/ as well.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Note that there are two "uri"s in the patch that need to be replaced. If it still doesn't work I don't know what's wrong, I'm not in a position to test at the moment.

Comment 5

[Amar Takhar]

Yes, I did change both..

Comment 6

[Topher]

I really need to vote this up.  I wish I could code it.  :(  I'm not the only one, look at the vote pool: https://support.mozilla.com/en-US/questions/801625  The new "functionality" annoys me every single day.

Comment 9

[houkouonchi]

Uhm so wtf? Make an option to get the old behavior back, please. I am sorry but whoever thought it was a good idea to just change the behavior that much without allowing for the ability of setting it back was a bad choice.

I use this feature 50+ times a day and it now wont work in 95% of the cases I normally used it. I mean honestly if your doing a middle mouse paste with a full url (including http://) then it was probably a proper hyperlink to begin with and what is the point of even having this feature?

Comment 11

[Dean Serenevy]

Another help forum reference: http://support.mozilla.com/en-US/questions/792183

Comment 12

[Paul Wise]

Here is a patch for this:

http://shallowsky.com/blog/tech/web/firefox4-content-load.html

Comment 13

[Mike Hommey [:glandium]]

Essentially, it's the same patch as Gavin's, except for a few details.
Most importantly, what particular flags should be passed to createFixupURI? FIXUP_FLAG_ALLOW_KEYWORD_LOOKUP might be dangerous. FIXUP_FLAGS_MAKE_ALTERNATE_URI may be wanted.

Comment 14

[Paul Wise]

Keyword lookup isn't useful to me. As for alternate URIs, I would say it should get the same treatment as when you type something and press enter in the URL bar.

Comment 15

[Szókovács Róbert]

Will some the patches in this bug be committed? They don't seem too intrusive.

Comment 16

[db]

Come on - some action please - this is really annoying!

Comment 17

[Thomas Ahlblom]

WFM:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27

Reproduced:
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/5.0 (X11; Linux x86_64; rv:12.0a2) Gecko/20120303 Firefox/12.0a2
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120303 Firefox/13.0a1

Comment 19

[Thomas Ahlblom]

Why has the affected statuses been removed from this bug?

Comment 20

[:Gavin Sharp [email: [e-mail]]]

Because they're unnecessary. The tracking flags are used for indicating the status of tracking+ bugs, it doesn't serve a useful purpose to set them on every bug.

Comment 21

[db]

This bug is mega annoying - I wish there'd be a fix.  At least put an X in the location bar so it can be cleared and pasted into without hassle!

Comment 22

[insaner]

let me join the choir here, this is super annoying. why was this functionality changed? and whens the fix expected to be rolled out??

Comment 23

[Quel Qun]

Fedora 18 - FFox 17.0.1. The patches cannot be applied any more since everything seems to be compiled and/or compressed.

Please, please provide a toggle in about:config or something to allow pasting IPs or file paths. I use it _all_the_time_.

Comment 24

[Alexander]

IMHO this feature should be made as user *unfriendly* as the above people want but leave it disabled by default for the non-expecting users like me. Moreover it behaves fragile for me. See bug 829714.

Comment 27

[Ioana (away)]

The behavior for loading URLs from the clipboard with middle click is inconsistent in the recent versions of Firefox. Sometimes it loads the URL, other times it doesn't even though I'm using the same steps (URL in the clipboard, middle click blank content on a web page).

Whatever you want the behavior for this to be it should be the same all the time.

I can reproduce this issue since about Firefox 20 on Windows 7 64bit, but (considering that it's intermittent) I can't find for sure if it's a regression.

Another annoying issue here is that sometimes the URL from the clipboard gets loaded when I middle click a link (in order to open it in another tab).

Comment 28

[Dmitry Bolkhovityanov]

Ouch, such an extremely annoying bug is 30 months without a fix!

Guys, if a proper fix is so hard to do, wouldn't it be wise to just revert back changes caused by bug 414345?  414345's "problem" is scarce, while this bug with disfunctional URL-pasting badly affects most advanced users.

Comment 29

[:Gavin Sharp [email: [e-mail]]]

Attachment: possible patch

To be honest I forget some of the constraints here. It seems clear that we don't want middle mouse pasting "foo" to result in a load of "http://foo", but "www.mozilla.org" should probably work. The issue is that we don't really have a great utility for distinguishing the two (and that is generally a hard problem in the face of a multitude of new crazy TLDs). We'd probably have that once we fixed bug 1080682.

Comment 30

[J.O. Aho]

Actually we want to try to load http://foo as 'foo' can be a host name in the local network or a alias for a site. 

If you want to make a proper fix which will make the former microsoft windows users happy and not break for the unix users, just see to test the connection and see if there is any content, if not, then complain about the URL, but of course that a lot more complex fix to do, so better just revert to how it has been working since day one, instead of having "fixes" which just pleases the former microsoft users and keeps on breaking for unix users.

Comment 31

[:Gavin Sharp [email: [e-mail]]]

We do not want to revert to the state prior to bug 414345 - showing modal prompts in response to middle mouse pastes is not desirable. My patch without the "contains" check might be a fine compromise, though.

Comment 32

[Michelle Funches - QA]

Reproducible
Version 	47.0.1
Build ID 	20160623154057
User Agent 	Mozilla/5.0 (Windows NT 5.1; rv:47.0) Gecko/20100101 Firefox/47.0

Comment 33

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates and 14 votes.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 34

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.