Middle mouse button invokes 'invalid URL'

Bug #353318 reported by gsmx on 2009-04-01
60
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox (Ubuntu)
Low
Unassigned

Bug Description

LATEST RELEASE TESTED:
Firefox 3.5

WORKAROUND (from upstream):
go to about:config and set middlemouse.contentLoadURL to false

Binary package hint: firefox-3.1

(Jaunty) Sometimes when just pressing the middle mouse button in Shiretoko 3.1 Beta 3 (Firefox 3.5), an alert prompt comes up. This happens when you don't click a link or anything, just some white area. The strange thing: it doesn't happen always, but it does a lot.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: firefox-3.1 3.1~b3+build2+nobinonly-0ubuntu1
ProcEnviron:
 LANG=nl_NL.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.1
Uname: Linux 2.6.28-11-generic i686

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.

gsmx (gsmx) wrote :

Binary package hint: firefox-3.1

(Jaunty) Sometimes when just pressing the middle mouse button in Shiretoko 3.1 Beta 3 (Firefox 3.5), an alert prompt comes up. This happens when you don't click a link or anything, just some white area. The strange thing: it doesn't happen always, but it does a lot.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: firefox-3.1 3.1~b3+build2+nobinonly-0ubuntu1
ProcEnviron:
 LANG=nl_NL.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.1
Uname: Linux 2.6.28-11-generic i686

gsmx (gsmx) wrote :
Alexander Sack (asac) on 2009-04-11
affects: firefox-3.1 (Ubuntu) → firefox-3.5 (Ubuntu)
Micah Gersten (micahg) wrote :

Thank you for reporting this problem to Ubuntu. Could you please try with the latest daily build of Firefox 3.5 for your Release and let us know if this is still an issue?
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa

Thanks. Please feel free to report any new bugs.

Changed in firefox-3.5 (Ubuntu):
status: New → Incomplete
Andrey Larionov (anlarionov) wrote :

I install from Mozila Daily PPA, but bug still here.
Looks like middle mouse button works as Paste command. Nothing wrong if clipboard is empty and "Invalid URL" message if in clipboard some inappropriate for URL content, If clipboard content is URL, then location of current window is changin.

Andrey Larionov (anlarionov) wrote :

My current version in which bug is reproducible is 3.5.1pre (3.5.1~hg20090704r26038)

Micah Gersten (micahg) wrote :

This seems to be by design. We'll wait to see what upstream does. I'm waiting to figure out which upstream bug is correct.

WORKAROUND (from upstream):
go to about:config and set middlemouse.contentLoadURL to false

description: updated
Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Low
status: Incomplete → Confirmed
Micah Gersten (micahg) wrote :

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:
https://bugzilla.mozilla.org/show_bug.cgi?id=366945

Changed in firefox-3.5 (Ubuntu):
status: Confirmed → Triaged
Changed in firefox:
status: Unknown → New

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

goto (gotolaunchpad) wrote :

This isn't a bug, this is the way Firefox (and Mozilla) have always worked. I find it rather convenient. Maybe this behavior could be enhanced by screening the clipboard for URL content before loading a new location?

Recent revisions have shipped with middlemouse.contentLoadURL turned off, and I've had to hunt through menus to figure out how to turn it back on.

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.

Jan Tiedemann (aeonspire) wrote :

It's still enabled in my 3.5.2 build. Where in the menus did you find the switch to turn it on?

Please consider that this is an important issue with the increased use of multitouch functionality.
I set my touchpad to 2-finger scroll but often it accidentally invokes a 2-finger tap in white space.
This in turn either sends me to an address fitting my clipboard contents or displays the even more annoying 'invalid URL' popup.

I suggest that either in about:config middlemouse.contentLoadURL is always set to false in general or just Ubuntu or that the firefox developers implement a simple and easy to find checkbox option in the preferences that enables/disables the feature.

Either way it would greatly improve the multitouch experience in ubuntu/firefox.

Thanks already for your efforts!

Micah Gersten (micahg) wrote :

Well, this issue is still open upstream. If upstream rejects it, then the Ubuntu devels would decide whether or not to change it by default. Usually, we like to keep the upstream prefs intact.

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.

Bastelnerk (bastelnerk) wrote :

+1 for changing default setting. it would be much better out of the box experience, especially for netbook users

Bastelnerk (bastelnerk) wrote :

just installed karmic and the default setting has, in fact, been changed already! so this bug can be closed

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

Changed in firefox:
importance: Unknown → Medium

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

Changed in firefox:
status: New → Confirmed

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

In , Pppx (pppx) wrote :

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

Changed in firefox:
status: Confirmed → In Progress
Changed in firefox:
status: In Progress → Fix Released
affects: firefox-3.5 (Ubuntu) → firefox (Ubuntu)
Changed in firefox (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.