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.

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

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

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.

Yes, I did change both..

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.

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?

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

Here is a patch for this: http://shallowsky.com/blog/tech/web/firefox4-content-load.html

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.

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.

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

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

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

Why has the affected statuses been removed from this bug?

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.

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!

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

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_.

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.

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).

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.

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.

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.

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.

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