Closed Bug 135884 Opened 22 years ago Closed 13 years ago

Middleclick on browser content area loads clipboard as URL

Categories

(SeaMonkey :: Search, defect)

Product:
SeaMonkey
Component:
Search
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 366945

People

(Reporter: jwz, Unassigned)

References

Details

(Whiteboard: set middlemouse.contentLoadURL = false)

Attachments

(1 file)

Fix, v1 - switch default to false
1.30 KB, patch
Details | Diff | Splinter Review 
Ok, so, apparently if I have selected some text
in another window, and I middle-click to paste
it in a text field in a browser window, but I
*miss* and middle-click on the document itself
instead, it pastes that text into the *URL FIELD*
and starts trying to look it up as a host name????

That's got to be the stupidest thing I've seen in
a long time. 

How do I break the legs off of this horrid paste
target?  When I try to paste into a browser window,
I want it to do nothing, or at most, beep.

*** This bug has been marked as a duplicate of 85677 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Wow.  Talk about uninformative replies to bug reports...

Jamie, what you probably want is:

user_pref("middlemouse.contentLoadURL", false);

in your user.js or prefs.js file or in the unix.js file of your mozilla 
installation (where that pref is set to true by default).

Verified that the other bug would alleviate the default situation somewhat.
Status: RESOLVED → VERIFIED
Not a dup, REOPENing. The other bug just proposed to eliminate some cases, and
such heuristics are not a good idea IMO, and have been WONTFIXed (by others).
So, this leaves this bug again. Let's use this bug as tracking bug for those
people annoyed with the current "middleclick on content loads clipboard as URL"
and discuss solutions here. See for example
<http://bugzilla.mozilla.org/show_bug.cgi?id=85677#c57> for some possible solutions.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Summary: middle-click on browser window is an abomination → Middleclick on browser content area loads clipboard as URL
Most of the people discussing in the other bug seemed to like the idea of
exposing the preference in the prefs dialog.  That would be an easy solution and
perhaps the best, and there's plenty of room for another pref in the mousewheel
pane (it could be renamed to Mouse or Mouse Buttons).
*** Bug 147088 has been marked as a duplicate of this bug. ***
Related bugs include bug 85677, bug 111337, bug 70498, bug 63712, and bug 57317.
Blocks: 144260
Very often, this results from middle clicking a link and just missing it with
the mouse. I'd suggest the following behaviour should result from a middle click
which is in the content area.

IF (clipboard contains valid URL), go to it in current window.

ELSE IF(mouse is within 5 pixels of a link), Open that link as new tab

ELSE do nothing (or give error message).

I'm certainly always finding case 2. I want tabbed browsing, and where this link
is is on 2 lines (eg theregister.co.uk), clicking in the middle results in a miss.
I vote for simply exposing the existing pref in the UI, as suggested in comment
4. No heuristics, please. The pref panel could also mention bug 111337.
Another problem is "just missing" a text entry field when you're trying to add a
URL to the beginning of a line.  (Think complaint forms.  Or places where an
example URL would be pasted in...)

Sadly, it's not just missing the links.  And the links are (usually) larger than
the space just at the beginning of a line in a text field, where (under Linux,
at least) the pasted text goes where you've clicked.
This issue crops up in another way for me.  From my use of Firebird (0.7) in
Windows and Linux, middle-clicking a tab would close the tab.  In FireFox 0.8,
middle-clicking a tab in Linux will paste the contents of the clipboard into the
location and try to load it (and the tab I middle-clicked will not close).
(In reply to comment #10)
> This issue crops up in another way for me.  From my use of Firebird (0.7) in
> Windows and Linux, middle-clicking a tab would close the tab.  In FireFox 0.8,
> middle-clicking a tab in Linux will paste the contents of the clipboard into the
> location and try to load it (and the tab I middle-clicked will not close).

Oops, the problem I described is bug 171132.  The suggested preference above
(middlemouse.contentLoadURL) is a working fix for 171132.
*** Bug 258757 has been marked as a duplicate of this bug. ***
I for one would very much like to see this highly aggravating mis-feature
disabled by default.

It has been reported many, many times: bug 52185, bug 57317, bug 62759, bug
64559, bug 67839, bug 70498, bug 75414, bug 85677, bug 96972, bug 107147, bug
111148, bug 111337, bug 127689, bug 135884, bug 147088, bug 147088, bug 171132,
bug 226747, bug 228453, bug 258757, bug 274773, bug 278290 ... (possibly not a
complete list).  Read the comments there to see some *very* frustrated users. 
The typical response is to mention the workaround pref and to mark the bug as
DUPLICATE, INVALID (which is incorrect) or WONTFIX (which is at least honest, if
insensitive to the wishes of the users).

I have a proposal which may satisfy the few people who do use this feature, and
yet turn down the annoyance level for everyone else:

the default state should be (middlemouse.contentLoadURL="sometimes"):

1. middle-click into a foreground window does nothing
2. middle-click into a background window loads whatever is in the clipboard but
*only* if it starts with a valid schema

the rationale behind (1) is that you can just middle-click into the url bar

changing the pref to false disables url loading from middleclick completely

changing the pref to true enables loading when middleclicking foreground windows
and when the clipboard does not contain a valid/complete url

Comments?
I should mention that having an obscure hidden preference that deals with this
is only a *workaround*, not a fix.  Most people who experience the problem
(which is basically everyone, at least occasionally) will not find that.  The
existence of a workaround is no reason not to fix this.
I don't think it is a good idea to handle middle click differently for foreground
vs. background windows, and finding good heuristics to distinguish URLs from text
is pretty much impossible (see bug 85677).

See also bug 216899 and bug 291768 on middle click vs. autoscroll in Firefox.
What is a real nuisance is when I am trying to paste data into a form field, and
miss by a few pixels. Then the result is that my password, or whatever data it
was is exposed to the rest of the world as a DNS lookup!

So how about disabling middle-click-past-to-URL if the mouse position is within
10px of a form element. 
> So how about disabling middle-click-past-to-URL if the mouse position is within
> 10px of a form element.

there's already a separate bug for that.
(In reply to comment #15)
> I don't think it is a good idea to handle middle click differently for foreground
> vs. background windows, and finding good heuristics to distinguish URLs from text
> is pretty much impossible (see bug 85677).

foreground vs background: afaik that was the behavior in Netscape 4.5 for unix
that this feature is trying to reproduce.  it would completely ignore
middle-click in foreground windows, but middle-click in background windows would
load.  that has a tolerably low annoyance quotient, but mozilla changed it to
work in foreground windows as well, hence all the complaints.  whether the
original behavior was a good idea is another question.

good heuristics: it is actually trivial to come up with a heuristic that has no
false positives and <1% false negatives - something like
/^\s*http://[^\s]*\s*$/.  false negatives are ok since you can always paste into
the url field.  false positives are not ok since they would be triggered by
accident.

in any case, the default for this should be off, and the preference should be
there in the ui for anyone who wants to turn it on.  i only suggested a special
behavior like middle-click in background windows as a compromise default state
which would be useful to both people who want this and those who don't.
> foreground vs background: afaik that was the behavior in Netscape 4.5 for unix

I don't have 4.5 to test, but it certainly was not the behavior for Netscape
4.8.  I fail to see what a different behavior for background windows would
accomplish except confusion.  A schema should not be required because I should
be able to middle-click-paste "www.mozilla.org" and have it load that.  There
are already checks in place to catch invalid URLs.  Try to middle-click-paste
"not a URL".
(In reply to comment #19)
> I don't have 4.5 to test, but it certainly was not the behavior for Netscape
> 4.8. 

just tried that, you are correct.  foreground vs background doesn't matter, but
a selection in a browser window couldn't be middle-click-loaded into the *same*
window (works fine into a different window).  that's is what confused me.

> There
> are already checks in place to catch invalid URLs.  Try to middle-click-paste
> "not a URL".

just tried that too, it loads "keyword:not a URL".  in my case
keyword.URL="http://www.google.com/search?ie=UTF-8&q=", so that does a google
search.  the default would be google "i'm feeling lucky" which brings you to
http://www.xml.com/cs/user/view/cs_msg/2701.  most people wouldn't have a clue
what just happened, if they were (for example) trying to open a link in a new
tab.  this is on firefox-nightly-2005-05-21-05 btw.  what do you see when you
try it?

incidentally, i read all of the comments to all of the related bugs i listed
above.  by my count, 48 people commented against and 14 in favor of the current
behavior.   8 people describe it as "annoying", 4 "irritating", 3 "unintuitive",
1 "insane" and 1 "plaguing my life" ;)

i think the people who like it do have a point, in that the *other* way of
accomplishing the same is quite cumbersome: switch to browser, double-click url
field to select, press delete, switch back to source of url, select url, switch
to browser window, middle-click into url field.  i think the real fix for this
has to happen together with some streamlining of the way that task works.  what
about middle-click in url field replaces contents unless the url field is
already focused?  that way, to append to a url (which is a somewhat rarer task)
you'd have to left-click and then middle-click.  the much more common task of
replace url will be handled by a single middle-click (perhaps requiring an extra
enter-keypress to load).

the people who hate it also have a point, because it does happen by accident all
the time when pasting into form fields (which everyone does) and when opening
new windows/tabs by middle-clicking a link (which many people do).  *everyone*
on unix suffers from this, they just learn to live with it, partly by being very
paranoid about not missing the target of a middle-click.  not good.  even the
people who use it as a feature have to worry about this.  i guess to some extent
it depends on what nuisance value is assigned to what happens when you trigger
this by accident, but as anyone who has filled out a form for half an hour only
to lose it all because of missing the last field while attempting to paste into
it, it can be pretty aggravating ;)

it is also not intuitive, because there is *no* unix app that opens a file with
a middle click (from a file path in the clipboard).  yeah, so netscape started
doing this and it is a somewhat well-established behavior, so what? 
middle-click link to open new tab/window is at least as well established, and
the two are frankly incompatible in practice. not to mention the other uses for
the middle-mouse button such as scroll and pan.

to summarize:

1. this should not be the default behaviour.  there is a strong consensus for
that (48 to 14)
2. leave it as a preference (hidden or not).
3. perhaps the same task can be accomplished in an equally convenient way by
middle-clicking in the url field, which has a much lower chance of "accidents".
> just tried that too, it loads "keyword:not a URL"

file a firefox bug.  suite won't do that.

> by my count...

you're ignoring all the people who like it but didn't comment because it already
"works".

> what about middle-click in url field replaces contents unless the url field is
> already focused?

that's entirely unintuitive and is inconsistent with the behavior of other text
fields.  It would also require hitting enter afterwards which defeats part of
the purpose of the feature (loading without keyboard)

> but as anyone who has filled out a form for half an hour only to lose it all 
> because of missing the last field while attempting to paste into it

hit the back button?  particularly now with bfcache.
Assignee: samir_bugzilla → search
Status: REOPENED → NEW
QA Contact: claudius
(In reply to comment #22)
> > just tried that too, it loads "keyword:not a URL"
> 
> file a firefox bug.  suite won't do that.

it will, if internet keywords is turned on.  keywords is simply on in firefox by
default (with no ui to turn it off or change server, actually).

in any case the contents of the clipboard will always get sent to the dns server
which is a security risk.

> you're ignoring all the people who like it but didn't comment because it already
> "works".

let them speak up, then.  they can set the hidden pref too ;)  look, this is a
major annoyance for a lot of people, i think we have enough evidence of that at
this point?  on the other hand i am convinced that the number of people who use
this feature or even know about is is quite small.  i'm open to any proposal
other than just let's ignore the problem.  maybe a poll on one of the newsgroups?

> > what about middle-click in url field replaces contents unless the url field is
> > already focused?
> 
> that's entirely unintuitive and is inconsistent with the behavior of other text
> fields.  It would also require hitting enter afterwards which defeats part of
> the purpose of the feature (loading without keyboard)

ok, so load immediately.  it's intuitive for me, esp. if
browser.urlbar.clickSelectsAll is also set (which it probably should be by
default).  think of it this way, the click selects first and then the paste
takes precedence to the copy that would have been triggered by the select, so
the result is a replace.

this was originally proposed by <mpt@myrealbox.com> in bug 70498, comment 15 and
independently in a couple of other places and seemed to garner some support.  i
like it too.

besides, talk about unintuitive, you now can "paste" into a non-editable area? 
and the paste is really an immediate open/load?  have you ever watched someone
who stumbles into this for the first time?  i have to second what jwz said, this
has to be the stupidest thing i've seen in a long time.

(In reply to comment #24)
> See bug 57317 comment 60.
(In reply to comment #60)
> This is a standard graphical browser behavior on X and has been since at least
> 1996 (when I first used a browser on X).  Further, it's correct.  Middle-paste
> should act essentially like drag/drop, and it does.  If you don't like X
> conventions, feel free to use a different window system with different
conventions.

I like X conventions fine, this just doesn't follow them.  Middle-click is
paste.  If your middle-click target is non-editable, nothing happens in X. 
Middle-click is not "load" or "open".  There is no other X app I know of in
which you can middle-click (for example) a file path into a non-editable text
(or image, or whatever) area and have it open a file.  Ditto drag and drop of a
file path.  Why should a web browser have a completely unique behavior?  Just
because it's been around for a long time doesn't mean it's a good idea.

*** Bug 299515 has been marked as a duplicate of this bug. ***
> i read all of the comments to all of the related bugs i listed

Did you read bug 85677 before suggesting heuristics? And bug 57317 etc. where
this has been discussed over and over?

FWIW, I consider this feature harmful as well. I do use and like the
middle-click paste on the page icon (directly left to the URL) as a replacement
feature, and would recommend that as the default.
(In reply to comment #27)
> > i read all of the comments to all of the related bugs i listed
> 
> Did you read bug 85677 before suggesting heuristics? And bug 57317 etc. where
> this has been discussed over and over?

Yes, I did.  While it is impossible to come up with a perfect heuristic, I don't
see why a heuristic has to be 100% in order to be useful, and I don't think that
was ever addressed there.  A heuristic with no false positives and few false
negativces should be good enough.

> FWIW, I consider this feature harmful as well. I do use and like the
> middle-click paste on the page icon (directly left to the URL) as a replacement
> feature, and would recommend that as the default.

Thanks!  I think we're running into a bit of a stone wall on this issue, there
is no amount of evidence or reasoning that would budge the people opposed to
changing this.  But I can hope, right?

I'm working on a middle-click-in-url-bar-replaces-url patch which I will post
shortly.  Any thoughts about what to call the pref to control that?
(middlemouse.urlBarReplace)  Also any thoughts on when it should not exhibit
that behavior? (currently when it already has focus, someone had suggested if it
had been previously edited but I am not sure how to implement that)
See bug 111337: there already is a special location to do middle-click URL load,
and that's the site icon/bookmark icon to the left of the URL bar. (I don't know
about FireFox, though.) If you disable contentLoadURL, you don't lose the
functionality, you just have to aim better.
Alex, make that 49.
I am one against having this option on as default.
I don't mind the "middle click in background opens a new tab with the url" as
feature (toggleable, and perhaps on by default).

I have reinstalled firefox so many times, and I promote linux to whoever seems
suited for it, but I cannot at ANY point justify the behaviour of a middle click
as it is now.

It has nothing to do with the X convention. As Alex points out there is no
convention or program stating that/acting like a middle click would "open a new
document", etc.. If there is a need for a paste-and-go feature, I would
recommend a keyboard shortcut - not something as common as middle clicking that
already has 2 other potential uses (autoscroll/open in new tab) - and that's
just in the foreground page.

If the argument to keeping this feature on by default is "we don't care - some
people use it", then I don't see how that fits into firefox' goal of "keep it
simple" and targeting the prime audience.
The new users of firefox will have a hard time figuring out what the feature
does - i myself was baffled when I suddenly while reading some text and tried
autoscrolling was thrown to a random site that had absolutely no relevance to my
reading...

When telling my girlfriend this bugreport, and of the 48(49) vs. 14, she looked
at me confused and replied "but wasn't firefox supposed to be the good guys?".
My only reply was that "well, it's a feature, not a bug, you know.. like Microsoft"

I hope the asignee will listen to my wish and the wishes of many firefox users.
I've been around since 0.6, so i'm not just a newbie complaining about the
temperature in the sauna :)

50. I hate it when Firefox loads something I didn't want to load, just because I
missed a link.
Rather than having it on by default, please consider creating a user preference
for it that is visible in the normal configuration dialog.

The URL bar and Search box ought to have the Windows style behavior to where
when I click the first time, the entire text is highlighted so that a paste
there or backspace key will clear it.  The thing is that if I have something in
the middle-button clipboard, that should not be replaced by this operation. 
When it's loaded and I have to triple-click then push backspace, my selection is
lost, being replaced with the previous contents of the URL bar or search box.

I would like to be able to highlight the text of a URL in any application on the
X desktop, fly over to Firefox, left click once in the location bar, then middle
click there to replace the highlighted text with my URL.  No keyboard should be
required for this, and I bet it does not interfere with any other expected
behaviors.

Though many people are more accustomed to the CUA keybindings and mode of
operation involving the mouse in the right hand and C-x, C-c, and C-v keys,
there are certainly many of us veteran X users who are trained to use the middle
mouse button and Emacs-style keybindings.  I've really gotten to like not having
to use the keyboard to highlight and paste...  Yes, it's nice to have C-c and
C-v work between applications, but it's that the middle-mouse has always done so
in X since I began using it in 1995.

On a similar note, I also prefer to have 'C-a', 'C-e', and 'C-k' do what I
expect as in Bash command line and Emacs, though of course many others will
prefer the CUA style bindings instead.  The worst offender --- used to be that
if I pushed Meta-Q in a text edit box like this one, Netscape Navigator would
immediately exit.  Meta-Q is `refill-paragraph' in Emacs.  It's totally habitual
to press that key as I type; weird and arcane, but true.
> I would like to be able to highlight the text of a URL in any application on the
> X desktop, fly over to Firefox, left click once in the location bar, then middle
> click there to replace the highlighted text with my URL.

Simply use middle click on the site icon in the location bar.

> On a similar note, I also prefer to have 'C-a', 'C-e', and 'C-k' do what I
> expect as in Bash command line and Emacs, though of course many others will
> prefer the CUA style bindings instead.

You can already enable Emacs keybindings in GTK2, which will then also work
in Firefox.
51.

Anyone who would actually want this to be enabled by default (basically long-time linux/unix guys) would know how to search the web to learn how to turn it back on...so I dont think that not having time to implement this into the preferences dialog should hold this back from being changed.

This should not be the default, it is not what most users expect their browser to do, especially since it is a completly different behavior from the winodws version.
I agree that by default, this feature should be disabled, or restricted to the URL bar.
*** Bug 322349 has been marked as a duplicate of this bug. ***
Netscape 4.8 supported this, but there's one important thing about NN 4.8: it did not use the middle mouse button for opening anything in new tabs, since it had no tabs -- so there was no conflict.

Other UNIX browser WITH this (mis)feature:
* Opera (I tested 9.0 preview 1)
* Konqueror (3.3.2)

Other UNIX browsers WITHOUT this (mis)feature:
* Epiphany (1.6.0)
* Galeon (1.3.21)
* Nokia OSB-Browser (gtk-webcore.sf.net)

So, the convention Boris mentioned in bug 57317 comment 60 isn't currently followed by every browser on Unix. This might have been true some years ago, but now it's not anymore.

It seems that the other GTK-based browsers don't support this, while QT-based do.  Should Firefox be more like Galeon/Epiphany or more like Konqueror? The former would seem natural for a GTK app, becoming more GNOME-ish with each release.

I haven't yet seen anyone who would really use this. Almost every Linux Firefox user I know complained to me about middle mouse button being broken. Those who know about the hidden pref have all disabled it. I don't know any single user, who has this feature consciously turned on.

Thus, middlemouse.contentLoadURL should be disabled by default. All those who really want it, are certainly l33t enough to switch that pref on. 
I like the behaviour of the entry box in the Google toolbar.  When you single-click the text from the last search, it's lit up, but NOT selected to the clipboard, and pasting there will replace it with the text you have in the clipboard.  Taking it's behaviour for the URL entry line would be a great solution.  (Hire that google guy if you can.)

If I triple click the URL entry text, I'd like it to be selected to the clipboard.  A single click should highlight all of it, but not select it to clipboard.  Pasting there should replace the highlit part, rather than clearing the highlight then inserting the pasted text.

So, you'd highlight the URL you want, or copy it to the clipboard, then single click in the URL bar to highlight everything, then paste over it, or push backspace to clear it then paste.  That would make it work entirely with mouse gestures, the way we like.
> A single click should highlight all of it, but not select it to clipboard.

Clicking on the site icon in the location bar already does this.

> Pasting there should replace the highlit part, rather than clearing the
> highlight then inserting the pasted text.

That is bug 76010, which is unlikely to be fixed (see bug 76010 comment #12).

> So, you'd highlight the URL you want, or copy it to the clipboard, then
> single click in the URL bar to highlight everything, then paste over it,
> or push backspace to clear it then paste.

Perhaps you should actually read the comments in this bug, see comment #32 and my comment #33. In short: Middle click on the site icon will do what you want. Left click on the site icon + backspace + paste should work as well.
Status: NEW → ASSIGNED
The fascinating discussion notwithstanding, can someone please explain why middlemouse.contentLoadURL is still set to TRUE by default? What is holding up the default pref change?

PS - I don't see how this bug is about 'Core|Search'
Regardless of how useful this feature[1] is for some of us, I think there are two problems with it:

- The feature is turned on by default. 'Power user' features turned on by default are fine if they do not interfere with basic usage. This is definitely a feature that affects / confounds basic usage of the browser. I think simply turning it off by default will alleviate a lot of the issues it is causing for people.

- It is not exposed in the preferences UI. The users that this will confuse the most (less-experienced users, perhaps attempting to migrate from Windows) are the ones who are not going to know of about:config or be capable of editing a javascript file to turn it off. 

I assume that those that like the feature are more capable of turning it on (even if it was just flipping a bit in the js file) explictly than many of the users who are confused by it. Perhaps I'm wrong in this...?

Why does middle-clicking in a non-content area causing the browser to attempt to go to whatever's in the clipboard make little sense?

(1) Two unrelated areas are affecting one another. I click on blank space over here, and up there the URL bar is affected. This is non-intuitive.

(2) The clipboard contents do not open up in a new browser window or new tab. They open up in the current tab/window, which will take users away from what they're reading/working on. Maybe if they're filling out or submitting a file via a web form, they will lose work. For example, I'm submitting a large image to my album on photos.yahoo.com. I'm waiting for it to load, waving my mouse around, and accidentally middle-click on a blank area of the page. Suddenly my image has stopped uploading and I'm on some random site. I have to hit back to go back to the photo submit form and re-upload it. 

(3) It's quite easy with some laptops and mice to accidentally hit the middle instead of the left button, and to suddenly find yourself at some random page. Not to mention scroll-wheel behavior.

(4) It's quite easy to miss a link you'd like to open in a new tab and hit the blank space adjacent to it, and end up with some random page in the current tab instead.

(5) Since this feature accepts any text at all, the user can end up at highly inappropriate sites, a problem especially in the workplace. Some workplaces have systems in place where if you visit a blocked 'inappropriate' site, the incident is logged and reported to your manager. Or, if you're a parent browsing the web with a child... 

[1] For clarity, I'm referring to the fact that middle-clicking on a non-editable content area in the browser pastes into the URL bar. It makes sense that middle-clicking in an editable area such as the URL bar or a textarea in the content area would paste the current primary selection.
*** Bug 337921 has been marked as a duplicate of this bug. ***
It appears that the defaulting is a little too aggressive.  Every time I install or update an extension, the value of middlemouse.contentLoadURL goes back to false.  I've just now nailed it down in my user.js, but wanted to (a) note this annoying behavior and (b) note how to work around it.

(I just fired up Firefox 1.5.0.4 for the first time, and after it automagically checked for extension updates the feature was turned off again.  At least this time I knew to check it immediately when I saw the word "extension" fly by.)
This is actually fixed, at least on 1.5.0.5 on Ubuntu.  It seems the loading url from clipboard by middle clicking only works by middle clicking on a tab.  I think the functionality should be switched to middle clicking in the url bar rather than the tab.  Closing the tab on middle click makes more sense.  Pasting to a text field makes much more sense than pasting to a tab.  

There's an extension at https://addons.mozilla.org/firefox/2671/ that allows adding a button to the toolbar to clear the url without it going to the buffer, so if that functionality is added, a linux user could just click that button and middle click in the url bar and it should go to that url.
Also if it's done that way, the user can verify that it actually is a url.
I used to not use Konqueror because of this missfeature... and I stuck to Mozilla.  Now mozilla does it, and I used konqueror for a while, untill I figured out how to do the 
middlemouse.contentLoadURL
trick in about:config

Who smoked the crack?

It's fine in windows, but in Linux somebody botched the UI convention... middle mouse means paste in text fields etc... it has never ment paste in static-read only pages....    and now middle mouse is starting to mean navigation.. (that lovely hockey puck type thing that saves my wrists)

I don't know what version you guys changed this setting in, but it **** me off, and I can't reccomend Firefox to people on Linux anymore (without going in and changing settings)  It's just way too confusing to have the page change randomly.

middlemouse.contentloadURL=true doesn't work at all anymore.  No way to middle-click and load a URL in any buffer (copy buffer on windows, select and/or (?) copy buffer on linux).  How is anyone getting this accidentally??
I think this has been fixed (at least it's ok in my version, 2.0.0.2 on Kubuntu), so this bug can probably be closed...
(In reply to comment #48)
> I think this has been fixed (at least it's ok in my version, 2.0.0.2 on
> Kubuntu), so this bug can probably be closed...

Well, sort of: bug 216899 made it so that enabling autoscroll disables the function of middlemouse.contentloadURL. But autoscroll is still disabled by default on Unix, at least in the official mozilla.org builds.
Status: ASSIGNED → NEW
Is there any way to get the old behavior back?  So that I can middle-click on an empty part of the window and cause the browser to go to the URL in the clipboard?  or at least make this work when middle-clicking on the content part of a new, empty tab?  Right now even middle-clicking on the Location bar doesn't work: it inserts the contents of the clipboard into the middle of the URL, which is not what I want.  I want middle-clicking to cause the browser to immediately transition to the URL found in the clipboard.
(In reply to comment #50)
> Is there any way to get the old behavior back?  So that I can middle-click on
> an empty part of the window and cause the browser to go to the URL in the
> clipboard?  or at least make this work when middle-clicking on the content part
> of a new, empty tab?  Right now even middle-clicking on the Location bar
> doesn't work: it inserts the contents of the clipboard into the middle of the
> URL, which is not what I want.  I want middle-clicking to cause the browser to
> immediately transition to the URL found in the clipboard.
> 

You can take a look at my clickngo extension https://addons.mozilla.org/en-US/firefox/addon/3842
Product: Core → SeaMonkey
Same Firefox bug: Bug 366945

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 (which should be forced to close in Seamonkey: Bug 284379).

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.

There is just one issue: quick open of URL from clipboard. This could be implemented via middle-click (or another paste) on the "Open new tab" button (as in FF already?), middle-click on the "Go" button, pasting on the window title, adding tab context menu item "Open from clipboard"... But not via pasting "just somewhere here".
i hate this behavior, too. every time i want to middleclick a link, and miss it by a pixel, instead of moving the mouse and trying again, i have to either go back in the history or dismiss a text-box first.
I don't like this behavior too.
I'm a computing student so I decided to make a patch to remove this behavior.

I looked for the code responsible for this behavior and I found that it was intended (not a bug).
Here are some explanations.

In fact, there are 3 cases :
+ when you middle click on a link (URL) -> open it
+ when you click on a text field (like the Google one) -> paste the clipboard
+ when you click anywhere on the page but a link -> try to open the clipboard content as a URL

The first case is common to all platform and is defined here :
http://mxr.mozilla.org/mozilla-central/source/browser/components/places/content/places.js#308

The second one is only true for Unix* and can be disabled via middlemouse.paste
See http://kb.mozillazine.org/Middlemouse.paste

The last one (concerning this bug) is also only true for Unixes and can be disabled via middlemouse.contentLoadURL
See http://kb.mozillazine.org/Middlemouse.contentLoadURL

If you wonder why it was enabled for us, it's because a majority of *nix users wanted it.
See https://bugzilla.mozilla.org/show_bug.cgi?id=24571#c7

Just another link to those who wants to understand how middlemouse.contentLoadURL is set to true or false according to their OS :
http://mxr.mozilla.org/mozilla-central/search?string=pref("middlemouse.contentLoadURL"&tree=mozilla-central

I explained the issue because I hope users from Google will read this bug entry and so won't file another bug, duplicating this one.

So, if you don't want Firefox to try to interpret the clipboard content as a URL and open it :
+ open a new tab
+ type "about:config" in the URL field then Enter
+ type "middlemouse.contentLoadURL" in the search field
+ double click on the line
+ true should change to false and the line should become bold (means the value is user defined, not the default one)
+ enjoy middle clicking anywhere (but a URL) ^^

(you're free to change others middlemouse values)
This bug is security relevant. If I paste a password for a website using middle-click into textboxes, and miss the textbox (easy, because middle mouse button = scroll wheel), that exposes the password to the network and the DNS server, without any SSL protection. Duh!

Note who filed this bug. jwz is the original author of Netscape for Unix.

I think most Linux users these days are more disturbed or confused about this behavior. I think we should just change the default, and let those people who like this behavior turn in *on*.
Whiteboard: set middlemouse.contentLoadURL = false
So, let's those people who like this just enable it, and let nobody be (badly) surprised anymore.

As for Android, I think that's either copy-paste from Unix, or just as useful for those small devices which do have a mouse.
i think it would be better to activate “Menu:Preferences → Pane:Advanced → Tab:General → Checkbox:Use autoscrolling” by default.

this effectively replaces this feature with a more sensible one (so if you miss a link you’ll just click any mouse button to disable autoscrolling agein)
Hey guys, we have a patch for this bug !
Having this one fixed for Fx4 should be really great.

I think it's the right approach but I may be wrong.
Can a 'regular' developer give his point of view ?

Before any commit, we have to submit a patch (done), getting reviews (flying sheep disagree) and address review comments (I think the patch is correct but more reviews would be great).

Please note that the bug is 'New' since 2002 with 30 users following it and 64 comments ...
The prefs are in shared code. Do it for Firefox in bug 366945 and we (SeaMonkey) will pick it up automatically. Unless BenB wants this only for SeaMonkey in which case he knows which files to modify in Suite.
Status: NEW → RESOLVED
Closed: 22 years ago → 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: