Middle mouse button invokes 'invalid URL'

You may want to go to about:config and set middlemouse.contentLoadURL to false

it's great that there is a setting to disable this behavior, but i'm more concerned about the impact to the user's psyche. i mean it seems to make no sense what is going on. i think that middlemouse.contentLoadURL should be set to false by default (preferably starting with firefox 3 because i that it is bad to change functionality in the stable release). thanks.

mike

I like the current behavior, though I mostly use Konqueror so I can't tell if it's for some reason a big usability issue in Iceweasel (Firefox); in Konqueror I haven't perceived it as a problem and use the feature frequently.

ok, i tried out the middle-click in konqueror, and i agree, it does work very well. when the clipboard text is a valid url, konqueror takes the user to that url. however, if the clipboard text is empty or contains non-url text, then it does not do anything.

if firefox behaved this way, i would be very happy. my primary issue with the functionality is what happens with non-url text.

so, my request is that firefox not do anything for a middle-click with non-url text on the clipboard, and to load the url if the clipboard text contains a valid url.

mike

I think it'd be *brilliant* for Firefox to check if the pasted text is a valid URL.

My main peeve is that it's a bit hard to middle click accurately on some mice. With a "rigid" scroll wheel, it's easy to end up scrolling up or down before middle clicking. This can move the page and so if you were trying to middle click on a link, you not only *miss* because the page scrolls (not Firefox's fault), but you get an annoying pop-up dialog box to click through (click-through dialog boxes bad!).

Just checking for illegal characters (line breaks, especially) would be awesome.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b3pre) Gecko/2007122004 Minefield/3.0b3pre

This behaviour is still present in latest cvs, and is very annoying.

middlemouse.contentLoadURL should be left true, but (I agree with john), Firefox should check to see if the clipboard contents are a valid url, as often I have random snippets of code in my clipboard.

*** Bug 497693 has been marked as a duplicate of this bug. ***

Ubuntu Bug:
https://bugs.launchpad.net/bugs/353318

My experience (Ubuntu 9.4, FF 3.5.1):
If you set middlemouse.loadcontentURL to false, you will be able to open sites in a new tab/window with the Middle Mouse Button and be able to paste the market text where you have your mouse pointer.

Just like it was in firefox 2 or 3.

Hope that helps.

This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
http://www.mozilla.com
http://support.mozilla.com/kb/Managing+profiles
http://support.mozilla.com/kb/Safe+mode

i've just tested the latest firefox. the behavior is much improved (compared to 2.0.0.x), but not as good as other browsers (webkit, konqueror, etc.). if a non-url is on the clipboard, you will now get a popup saying that is the case. however, that is really unnessary. it would be much cleaner if the invalid url were just ignored (like webkit, konqueror, etc.). thanks.

appologies, i must correct myself, there is no improvement. the text i tested with had a slash in it, but wasn't a valid url, which generated that error. however, using a simpler text without slashes, firefox still attempts to load that text as url. so, there has been no progress on this bug. thanks.

This is back on FF4 B2 and FF4 B3, the middlemouse.contentLoadURL option is enabled by default, disabling it does disable it as expected.

middlemouse.contentLoadURL is great but it should be disabled by default. Pasting on content area is anything but "open new URL here", and middle-clicking on the tab is the "close tab" action.

And all that on-the-fly URL parsing should be disabled too: it's useless (due to many different forms of valid URL including just selected [a-z]+) and brings uncertainty to all actions. If if thinks this time URL is valid it acts one way, if it does not -- it acts another way for same user action.

Mozilla is not M$ to take away the freedom of choice ;)

Older Mozilla Suite bug: Bug 135884
(Don't know is it a dupe or See also.)

*** Bug 135884 has been marked as a duplicate of this bug. ***

As I said in https://bugzilla.mozilla.org/show_bug.cgi?id=135884#c64, this bug is known for a long time now.

People who are annoyed can disable this behavior via middlemouse.contentLoadURL but disabling it by default is the way to go.

As Ben Bucksch said in https://bugzilla.mozilla.org/show_bug.cgi?id=135884#c62, the minority who prefers the current behavior could simply enable it.

For the others (the majority), the current behavior is surprising, confusing, not handy and is even security relevant (noticed by Ben Bucksch) when a user is pasting a password in a field but misses it by a pixel, sending the password through the network.

He wrote a patch but has never been commited.
Can someone review his patch ? (and possibly commit it ?)
>> https://bugzilla.mozilla.org/attachment.cgi?id=504212

Having this long standing bug fixed in Fx4 would be really, really great.

I disagree about disabling it by default. The common use case for this feature is where an URL is contained in a page text without a link (this is frequent e.g. in blog comments). For most cases, you can simply double-click on the URL, followed by a middle click (though it would be a nice feature to be able to open the page in a new tab).

Without this helpful feature, you would have to manually open a new tab and then move your mouse to the URL field and insert the text by middle-click there. Note that you cannot use Ctrl-V to do that. It is also not possible to easily insert the URL into the current tab's address bar, because you would first have to empty it. Double-clicking for selecting all text and pressing del/backspace won't help, as it overwrites the clipboard's content.

The security concerns are IMO indeed valid (I think it even happened to me at one time), but this can easily be fixed by allowing only valid URLs (but allowing for a missing http://), maybe additionally disabling the feature in close proximity to input fields.

As for the claim in comment #17 about only a minority wanting this feature: Can you back this up? Ben Bucksch in your reference certainly doesn't state that. And it obviously _is_ handy for the frequent situation I described above.

(In reply to comment #18)

> And it obviously _is_ handy for the frequent situation I described above.

And it is obviously (I believe) that full content area is not required for recent/frequent pasting URLs. We already have a web site icon area to paste URLs over it. And the new upcoming "Paste&Go" URL bar feature (in context menu). It's enough for opening links and not interferes with the loaded page active content.

I'd suggest to add this paste&go behavior (like web site icon has) to the 'Open new tab' button. Sure it have to open pasted text in a new tab (maybe not only URLs for the "URL bar search").

*** Bug 714361 has been marked as a duplicate of this bug. ***

*** Bug 829714 has been marked as a duplicate of this bug. ***

(In reply to chAlx from comment #19)
Yes, what about adding this function to:
* the former site icon area (load in the current tab),
* the Go button (load in the current tab)
* the New Tab button (load in a new tab)?

(In reply to Aleksej [:Aleksej] from comment #22)
The Go button suggestion would work only for an empty URL field. I thought of it because of “Paste & Go” which uses the clipboard and doesn’t work with the PRIMARY selection.

> Yes, what about adding this function to:
> * the former site icon area (load in the current tab),

Actually, this works, with some exceptions (bug 759060).

*** Bug 877233 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 667340 ***

It is the opposite, marking opposite bugs as duplicate makes it look as if one was in support of another.

That bug is now about the fact that the behavior for loading URLs from the clipboard with middle click is inconsistent. Some people request it to work one way, other the other way.

It would make a lot more sense for the people in this report to support their request there, where a decision about how this should work should be taken than let it separated and harder to hear. The reason I marked this one as a duplicate and not the other way around is that the other bug already has the attention of some developers.

In that case I'd suggest to make this bug depend on bug 667340 rather than making it a duplicate, or to retarget that other bug by changing its summary to reflect what it's about. I agree with Aleksej that a straight duping isn't applicable.

(oh, I see - you've renamed the summary already...)

Component: General -> Tabbed Browser. [bugday - 20131021]

*** Bug 926601 has been marked as a duplicate of this bug. ***

*** Bug 939447 has been marked as a duplicate of this bug. ***