When clicking the middle button on a blank area (non HREF) in a document, mozilla attempts to open whatever is in the clipboard.

I believe this is a feature. Netscape 4.x did this, and a number of people like it very much and rely on it. This is a Unix-only behavior, since you are effectively pasting the clipboard into the browser and the only reasonable thing to try to do on such a paste to a non-editable area is to open the contents as a URL.

Netscape 4.75 under Linux/X11 does not exhibit this behaviour. It's pretty unintuitive, if anything I would expect clicking the middle button on a blank area to open up a new browser window with the _current_ page.

Interesting. Netscape 4.75 on my system (Linux, X11) exhibits this behavior as have all versions back to 4.05 or so. I don't remember before then... There is a way to override this behavior with X resources for Netscape 4.x; perhaps this has been done on your system? It is maybe a little unintuitive (I found it very strange at first) but it is enormously faster than hitting C-l and pasting into the text field if you want to open a URL that's in the clipboard. And there is no good way to put the url from the clipboard into the URL bar, since highlighting the url bar clears the clipboard....

I don't see this on NS4.75, but I do see it in linux 2000102009. This is not only unintuitive, but really annoying. Everytime I hit the middle mouse button whatever is in the clipboard is pasted as the url and searched for. I scroll with my scroll wheel so accidental mouse presses in white space is normal for me. Furthermore, it also interferes with autocomplete. I was at bugzilla.mozilla.org and I accidentally hit mouse3, then it pasted my clipboard into the url bar. I closed and restarted mozilla, everytime I tried to type in bugzilla.mozilla.org it kept inserting the clipboard contents!! I'm pretty sure this is a regression because I have never noticed it before and I accidentaly hit mouse3 a lot! I feel that mouse3 should only open a new window when it's over a link, and do nothing otherwise ...

I think that having the scroll wheel also act as Mouse2 (middle button) was probably the stupidest thing that mouse manufacturers ever did. But this has been standard Netscape 4.x behavior on all the unix (Linux/Irix/Solaris) systems I have ever used. As for its being a regression, see bug 37030, which is all about how the middle mouse button should paste the URL. Arguably, this behavior should be a pref. In that case, I suggest closing this bug and opening one in which we request a pref for this behavior. As for pasting into the URL bar, well, that's standard X behavior for applications. Highlight selects, middle-click pastes. This can probably be disabled by telling your X server that you have a two-button mouse.

I really don't mind if it is a pref or not, but it should definately NOT paste into the location bar if I press mouse3 somewhere else ... if I press it in the location bar then that's the expected behavior.

over to toolkit. is clipboard toolkit or apps? Is there a specific person that handles clipboard stuff?

This is already a pref, but it's hidden (bug 55704).

so this is really a duplicate of bug 24571 then?

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

ok, this has been working for me the last few builds, the middle mouse button now works like it should. WFM linux 2000103008.

reproter: do you see this on new builds?

I still see this on current builds (2000110221). It is really very irritating, and I've never seen it on Linux or Solaris with extensive experience with Netscape > 4. Asa, this isn't a dup of 24571. That bug is for middle clicks in general. The problem here is that middle clicks <i>in a text field</i> should paste. Middle clicks that occur not in a text field should not paste, and instead they do, and to a weird and unintuitive location (the URL bar.)

adding blake. setting bug status to New.

Still seeing in new builds?

I still see it in 2000120306. Am re-summarizing to make the bug more clear.

It opens a _new_ browser? It does not just open the url in the window into which you pasted?

Doh. fixing that.

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

over to XPApps.

nav triage team: Pref sounds like the best way to go, but don't think we'll have time during beta1, marking nsbeta1-

akkana/anthonyd, could this be a selection/editor issue...?

It's a pref (so that we can turn it off for Windows/Mac users; Unix Netscape has always had this behavior, and it will continue to be the default on Unix). Read the comment from Jesse Ruderman 2000-10-24 17:14. Suggest marking the bug WFM and the people who don't like it can set the pref.

I'm home on vacation, so I can't state this with absolute certainty, but I'd be willing to be a small amount of money and a large amount of pride that the current behavior is /not/ the default behavior of NS 4.x under Unix (at least Solaris and Linux, which is all I have experience with.) Whether or not I am correct in that, it is a pretty irritating preference that really doesn't make much sense- in every other sane app I've ever used, on any platform, attempting to paste while you are not in a text entry field is a no-op. So, if that was the 4.x behavior, then it was a bug in 4.x and mozilla, and if it is only mozilla behavior then it is still a mozilla bug. As far as marking WFM- I'm against that. I'm fine with leaving the preference in there (I could see how people might find this useful, if a bit non- standard), but the default behavior should be to leave this "feature" off and let people turn it on if they need or want it for some reason. Otherwise, we are making mozilla behave in a completely non-standard way by default. Since the preference is not exposed by a GUI (and it is therefore hard to know how to make it behave in the default manner) this is even more pressing, I believe.

It has always been the default behavior on Unix Netscape. Honest. Try it, and first move your ~/.netscape/preferences.js and your .Xdefaults aside and do something like xrdb -l /dev/null to make sure your X defaults are gone. I won't take your money. :-)

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

With the default settings on RH6.2 and Netscape Communicator 4.75, NC4.75 will NOT paste text i've selected on the page into URL field when i click middle-button. It WILL paste it if i move cursor to URL field and focus it, and it WILL paste it into a form field if i focus that. I never manupulated any settings for pasting under X or NC - it just works like described "outta the box". So that is what i'm used to: No pastes lands unexpected places when i middle-click on an empty space on a page. What happens instead in 4.75 on RH6.2 if i have selected text and then middle click somewhere on page, is that selection gets de-selected again. No paste occures. If NC 4.75 or RH is somehow "pretuned" for the behaviour i observe, it should be tuneable for mozilla as well. This does seem like an xp4 issue to me.

I agree with liv@duke.edu's comments drom 2001-01-02 22:26. akk, I don't remember ever having seen this behaviour in 4.x Unix. It's not my prefs: [ben ben]$ cat .Xdefaults *blinkingEnabled: False *noAboutSplash: True [ben ben]$ I won't publish my prefs.js here, but I am not aware of such a pref, so I certainly didn't set it manually. I use the Redhat Netscape Comm. packages, maybe Redhat configured it so by default, dunno. I agree with luke that this behaviour is against all conventions and should be off by default. The prefs I saw do not help, because I need middle-click paste for pasting in textfields etc.. It is the 'loading on paste on background' which is IMO broken, not the middleclick paste (the latter just makes the former appear more often). I filed a dup bug, there is a bit more discussion. Especially, Moses Lei suggested to limit the drop-area to a special place, like the URL-proxy icon. This would be the best of both worlds IMO, and much better than a pref.

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

just filed bug 64577 - a clue to some of the unexpected evil pastes one sees in mozilla and not in 4.75

oops. testing, it seems the situation in 64577 does nothing.

Ah, from dark's comments in bug 64559 I finally see why some of you say you don't see this in 4.x. In 4.x, if you copy in a browser window and middle-mouse into the same browser window, the selection disappears and nothing happens. But try selecting in another app (e.g. an xterm) and middle-mousing into the browser window. That's the behavior so many of us have come to rely on in 4.x and earlier versions. As for the pref, sure, rename the pref to make it different from middlemouse.click. That's completely trivial. I'll attach a patch to do that. Of course, feel free to rename the pref if you don't like my off-the-cuff "middlemouse.contentLoadURL". You're on your own for the pref UI, but if someone wants to do it, here are the four middlemouse prefs and you might as well include them all: middlemouse.paste, middlemouse.contentLoadURL, middlemouse.openNewWindow, middlemouse.scrollbarPosition.

r=timeless

Okay, if people like the patch, I'll take this bug and check it in.

Um... should that new pref be false by default? That is, if we check this in, will we get a slew of "pasting to open a url stopped working" bug reports?

It's false by default in all.js, overridden to true in unix.js, just like middlemouse.paste itself. So on by default on Unix, off on other platforms.

Anyone know who the right person is to sr this?

akk, try hyatt.

sr=hyatt

Fixed.

Ahhhh :))) "...giant leap for mankind". Been looking forward to this one! user_pref("middlemouse.contentLoadURL", false); in prefs.js works fine. End Of Headache. Verified fixed, if I may. 2001-011021

I would like to have this enabled on windows. Well before this bug was Fixed it worked (a long time ago). Now I can not get it to work on any recent build. I have set to true all four middlemouse.* prefs and it will not work for me. Is there anything odd I must do to make this work under windows?

I recommend that you file a new bug on the fact that this is not working on windows; that's a different bug from this one. I'm not sure who it should go to (maybe the default owner for browser-general?). Post the new bug number here so anyone who's interested can join the cc.

Probably http://bugzilla.mozilla.org/show_bug.cgi?id=63950

i tried disabling this in linux build 20010124 by putting user_pref("middlemouse.contentLoadURL", false); in my ~/.mozilla/user/..../prefs.js, and when that didn't work, also in mozilla/defaults/pref/unix.js, but middle clicking in content area still tries to open clipboard as an url. am i doing something wrong?

Janne: Make sure to quit mozilla *before* editing prefs.js manually (do a ps also, and kill eventual mozilla-bin processes.) If you modify prefs.js manually while moz is still running, the manually edited changes are overwritten when moz exits. So quit the app - edit .mozilla/Default/..../prefs.js and paste in user_pref("middlemouse.contentLoadURL", false); Make sure the file ends with a linefeed - save - restart mozilla. Now it should work.

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

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

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

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

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

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

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

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

For those of us frustrated by this feature, this fix would be easier to find if the summary (either alternatively or additionally) included the expression favoured by the UI (e.g. Edit/Preferences/Tabbed Browsing) - namely 'middle-click': e.g. 'Middle-click on blank area opens clipboard contents as URL in current window.

I don't consider this fixed, at least while the behaviour is enabled by default. A hidden pref is nice but it is only a workaround which most people will not find. Please see my comments in bug 135884, comment 13. Perhaps we should make bug 135884 which is currently open the tracking bug for this? 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 ...

(In reply to comment #57) > For those of us frustrated by this feature, this fix would be easier to find if > the summary (either alternatively or additionally) included the expression > favoured by the UI (e.g. Edit/Preferences/Tabbed Browsing) - namely > 'middle-click': e.g. > > 'Middle-click on blank area opens clipboard contents as URL in current window. I second that suggestion. It should still be disabled by default.

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.

(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. This is horseshit. Just because X does something for 20 years doesn't mean it shouldn't wake up and fix its usability problems. Besides, what you say IS somewhat correcct, but ONLY when the actual clipboard content is pasted into the ADDRESS BAR. The CURRENT behavior is trying to load a URL from the clipboard no matter where the cursor is. THIS is WRONG, and it is a TERRIBLE usability because it is not obvious what the hell is going on.

If this were a usability problem, I would agree with you that it should be fixed. But it's not. In fact, it's a usability boon -- there is no other way to easily load a url that was "copied" somewhere via highlighting it. > but ONLY when the actual clipboard content is pasted into the ADDRESS BAR. This is PRIMARY content, not CLIPBOARD content. And if middle-click happens over the address bar, the text should be inserted at the click position, not replace all the text in the address bar. Which brings us back to my earlier point in this comment. Again, I'm not sure why you're not complaining about the way drag and drop works -- it works the same way as middle-click, which is how it should be. It sounds like you have a very wrong mental model of PRIMARY as a clipboard where copying and pasting happen, etc. That's not what it is. The drag and drop mental model is much closer to the way things work.

(In reply to comment #62) > If this were a usability problem, I would agree with you that it should be > fixed. But it's not. In fact, it's a usability boon -- there is no other way > to easily load a url that was "copied" somewhere via highlighting it. Boris, it is a usability problem. It's been reported as a bug something like 22 separate times so far. Lots of people have complained, sometimes in very irate terms. The problem is that it gets triggered by accident, with results ranging from harmless-but-annoying to really bad (dataloss, security compromised). I agree with the rest of your point, there should be another way to easily accomplish the same task. Middle-click to replace url bar is the obvious one.

(In reply to comment #63) > Middle-click to replace url bar is the obvious one. Oh, and to address your point about middle-click equals drag-and-drop: 1. drag-and-drop text into the content area does nothing, it does not try to load it as a url 2. drag-and-drop links into the url bar replaces the url bar and loads 3. drag-and-drop text into the url bar does nothing (not even paste) I would be absolutely happy if middle-click behaved exactly the same way (except for #3 which is probably a bug and should be changed to paste).

> The problem is that it gets triggered by accident How so, exactly? > 1. drag-and-drop text into the content area does nothing It loads the URL if the text happens to be a URL in Seamonkey and Firefox. It doesn't show a "URL is not valid" alert if it's not a URL (but in Firefox it does a Google search on the text instead). If what you want is for middle-paste to do the same, then that would be a separate bug, no? > 2. drag-and-drop links into the url bar replaces the url bar and loads Not in Seamonkey. If find this behavior in Firefox very counterintuitive (not to say incorrect). > 3. drag-and-drop text into the url bar does nothing (not even paste) Not in Seamonkey. Please file bugs on the Firefox UI being broken as needed.

(In reply to comment #65) > > The problem is that it gets triggered by accident > > How so, exactly? By missing the target of a middle-click by one pixel, either when trying to open link in new window/tab or when trying to paste into a form field. Both of those are very common actions with predictable occasional misses. Please see the comments to all the bugs I listed in bug 135884, comment 13. > > 1. drag-and-drop text into the content area does nothing > > It loads the URL if the text happens to be a URL in Seamonkey and Firefox. It > doesn't show a "URL is not valid" alert if it's not a URL (but in Firefox it > does a Google search on the text instead). No, I've verified that drag and drop text, urls or links into the content area really does nothing in Firefox and Seamonkey (Firefox nightly build 2005-05-21, Seamonkey 2005-07-01).

Trying to analyze and hyper analyze here is a waste of time. The point of the matter is, most people find this behavior problematic, it startles them, it surprises them (and so usability goes out of the window when this happens). This should be an enough indication for the maintainers to nuke that "feature".

> By missing the target of a middle-click by one pixel The same is true of most other UI actions when you miss the intended target area. Menus, say. Or drag/drop. > No, I've verified that drag and drop text, urls or links into the content area > really does nothing in It works just fine in a 2005-07-02-07 Seamonkey trunk build, as well as several Firefox builds (nightly from 2005-07-02, debug builds from 2005-07-01) over here. I'm not sure what you're testing and how to get this to not work. Just dragging the contents of the URL bar of this window to another window's content area loads this bug in that other window. Eugenia, unless you have hard data that more people find this behavior confusing than useful, please try to at least be polite, ok? Failing politeness, attemt constructiveness (if you're suggesting removing the only sane way to load a link in PRIMARY in a Mozilla window, then a replacement with similar affordance is needed).

(In reply to comment #68) > > By missing the target of a middle-click by one pixel > > The same is true of most other UI actions when you miss the intended target > area. Menus, say. Or drag/drop. Usually a miss results in nothing happening. Menus have histeresis, by the way, for pretty much that reason. > It works just fine in a 2005-07-02-07 Seamonkey trunk build, as well as several > Firefox builds (nightly from 2005-07-02, debug builds from 2005-07-01) over > here. I'm not sure what you're testing and how to get this to not work. Just > dragging the contents of the URL bar of this window to another window's content > area loads this bug in that other window. Dragging the url bar contents is the only way that works. Dragging a link from the content area does not work, and dragging text from one content area to another does not work either, even if that text contains a url. > Eugenia, unless you have hard data that more people find this behavior confusing > than useful I provided such data (the current count of people who have voiced an opinion in against or in favor of this feature is 49 to 14), and also suggested a newsgroup poll as a definitive way to settle this if people thought that was not good enough. The problem is that all complaints have been very persistently ignored or given the cold shoulder for a long time, so I can understand how politeness can start to fray. > then a replacement with similar affordance is > needed I agree absolutely, actually I am working on a patch that does just that. I will post it to bug 70498 which seems like the right place for it.

> Dragging a link from the content area does not work Works fine here... So does dragging text from this very textarea to a different window. So clearly you and I are doing something different. > the current count of people who have voiced an opinion That's not data. That's advocacy. People who use the feature have no reason to know about these bugs and no need to comment in them. Data would be a usability study. Again, this is a feature that browsers on Linux have had for a very long time. Every single Linux graphical browser (Opera, Konqueror, Netscape 3, Netscape 4, Mozilla) has it. If it's to be removed, there needs to be very good data showing that it's harmful (anecdotal evidence really doesn't cut it in such cases, I'm afraid) and an obvious migration strategy for all the current users who are using this feature and have been doing so for years.

(In reply to comment #70) > People who use the feature have no reason to > know about these bugs and no need to comment in them. On the other hand I think most people never in their wildest dreams think this could be a mozilla bug, let alone feature. Most would assume some type of obnoxious or buggy javascript got triggered. Most never even figure out that the site they end up on had anything to do with the contents of the clipboard (see some of the comments along the lines of "ahh, so that's what it is" - and those are generally pretty experienced users if they hang out here). So I would argue the number of bug reports seriously underrepresents the problem. > Data would be a usability > study. Please suggest a concrete plan that can actually be implemented to resolve this. I don't have X amount of money to conduct a formal usability study, and I imagine neither do you. I suggested some type of poll, or perhaps changing the default behavior in the nighly builds and try to gauge the level of complaints from that ;) > Again, this is a feature that browsers on Linux have had for a very long time. Is it documentated anywhere in mozilla? (Not anywhere I could find) If not, what makes you think many people know about it? > If it's to be removed, there needs to be very good data > showing that it's harmful (anecdotal evidence really doesn't cut it in such > cases, I'm afraid) and an obvious migration strategy for all the current users > who are using this feature and have been doing so for years. It's not to be removed, just disabled by default. I am honestly not sure how to handle upgrades, but I think if there was a pref for middle-click-replace-urlbar and the release notes said upgrading changes middleclick.contentLoadURL to false and sets middleclick.replaceURLBar to true, that might be reasonable.

In exchange for removing a feature that many linux users depend on heavily, you're proposing to replace it with a new pref which would remove yet another important feature, the ability to paste text at a specific place in the urlbar? If the problem is that it's too hard to discover the hidden pref, write some documentation or lobby for exposing the pref. We've had enough functionality regressions as it is; no need to seek out new ones.

(In reply to comment #72) > In exchange for removing a feature that many linux users depend on heavily, > you're proposing to replace it with a new pref which would remove yet another > important feature, the ability to paste text at a specific place in the urlbar? Not exactly, the replace will only work if the urlbar is not already focused. Left-click+middle-click will always insert at a specific place, middle-click on an unfocused urlbar will replace. > If the problem is that it's too hard to discover the hidden pref, write some > documentation or lobby for exposing the pref. We've had enough functionality > regressions as it is; no need to seek out new ones. That's part of the problem, and I certainly would like to expose the pref (although that idea has been shot down before). The other part of the problem is that *the default is wrong*.

All I know is today in Mozilla/5.0 (X11; Linux i686; rv:12.0a2) Gecko/20120309 Firefox/12.0a2 Iceweasel/12.0a2 I shall train myself to be very very very sure the pointer is really fully inside the textbox before hitting that middle button.