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
Last Resolved: 17 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. ***
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 <email@example.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.
See bug 57317 comment 60.
(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'
*** 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 18.104.22.168 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 22.214.171.124 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, 126.96.36.199 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, 188.8.131.52 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.
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
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
Last Resolved: 17 years ago → 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 366945
You need to log in before you can comment on or make changes to this bug.