I appologize for not using Mozilla M13 to submit this form. All other attempts were unsuccessful apparently from other bugs. M13 is the release I was using when this bug happened. I am using Windows 2000 Final (5.00.2195) which was upgraded from Windows 98 Second Edition, which had Microsoft Intellipoint 3.0 installed. I am using a Microsoft Intellimouse Explorer mouse, attached to the PS2 port using the USB- PS2 adapter which was provided. This bug can be easily replicated. Simply select some text and copy it to the clipboard. I selected "Netscape was first, and Netscape will be Last". Go to any website of your choice and attempt to click the wheel mouse down (which invokes auto-scroll in IE 5/4). It will paste the selected text into the URL field. The result was "http://www.Netscape was first, and Netscape will be Last.com/" and it displays an error message "www.Netscape was first, and Netscape will be Last.com could not be found. Please check the name and try again." The debug output is follows: S_OK nsDataObj::GetData2 ->>>>>>>>>>>>>> Read Clipboard from memory S_OK ->>>>>>>>>>>>>> Write Clipboard to memory ->>>>>>>>>>>>>> Read Clipboard from memory URL on clipboard: 'http://www.Netscape was first, and Netscape will be Last.com/ '; length = 61 FindShortcut: in='http://www.Netscape was first, and Netscape will be Last.com/' out='null' Error loading URL http://www.Netscape was first, and Netscape will be Last.com/ Document: Done (0.08 secs) WEBSHELL+ = 6 nsXULKeyListenerImpl::Init() WEBSHELL+ = 7 WEBSHELL+ = 8 commonDialogOnLoad WEBSHELL- = 7 WEBSHELL- = 6 Move window by 309,149.6 screen x 0screen y 0 WEBSHELL- = 5

I'm pretty certain that this is feature rather than a bug (middle mouse button is supposed to load urls if you click it on the page). However see bug 24571 for a possible future solution...

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

Assigning to default owner.

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

Hmm. Was this intended to be a feature on Windows? Sounds like it is trying to effect the load by pasting into the URL bar and faking the Enter (read KLUDGE?), rather than going through the usual page load mechanism. Assigning to akkana per pavlov, and cc'ing pavlov.

Yes, it's a feature, which a lot of people want. There is already a bug on making this prefable for people who don't want it; marking this a dup of that one. Regarding Peter's "KLUDGE" comment, as far as I can tell, we're using the standard way to go to the url bar (there's no enter being faked, and navigator.js doesn't seem to have an API to go directly to a url without first putting it in the urlbar). Peter didn't bother to leave himself cc'ed on this bug, so I'm sending him mail separately to see how he thinks this is supposed to be done. *** This bug has been marked as a duplicate of 24571 ***

I'm sure I don't know anything you don't, Akkana. No doubt you are right, I was just combining my impression with a comment from pavlov about faking the Enter. Sorry about the parenthetical kludge comment, but I did use a question mark. I thought we always used to load the page before displaying the URL, but was this platform-specific? Windows 4.x seems to load the page before displaying the URL. It seems like we'd only want to have valid, loaded URLs in the URL bar, unless the user explicitly entered it. The current method leaves bogus URLs. As to this bug being a dup of 24571 - are you sure? It sounded to me like the reporter was middle-clicking in the page, and the URL got inserted in the middle of the URLbar text. When it works, it should replace entirely, rather than insert, right?

As I understand it, 24571 covers both general middle-mouse pasting (into any editable field) and also the feature of middle-mousing in the browser content area to go to a new page. They'll probably be on the same pref.

When the pref is set, and the user middle-clicks in the page, should the clipboard URL a) be inserted into the middle of the URL bar, or b) entirely replace the contents of the URL bar? If (a), then this bug should be separate, and open.

b -- it should go to that url, just like it always has on unix. It should only be inserted in the middle of what's already in the urlbar if the user middle-clicks in the urlbar (and the insertion will be at the mouse position) -- again, as Unix has always done. They both work now, more or less, though the former case (middle-click in the content area) is working inconsistently right now due to problems in the workaround for bug 23669 (awaiting a real fix).

Sure, but this bug report is not citing any problems on Unix, only Win2000. It seems to describe middle-clicking on the page resulting in the URL being inserted into the URL bar, which would be a separate defect from 24571, not a dup. Note that this is also using MS IP3.0 mouse, which may add its own features. Perhaps the original reporter will clarify where the click occurred.

per offline conversation with akkana: reopening bug in case the reporter was clicking in the page, or possibly reporting a Win2000/MSIP 3.0 specific defect.

Adding dependency for the bug on adding a pref. Marking M15 because that's what 24571 currently is.

The original bug was about a mouse-wheel click. Isn't that different from a middle-button click?

On wheel mice, the wheel *is* the middle button. And there are some wheelmouse users who want to be able to use the wheel to scroll, without losing their middle-click functionality. Hence we need a pref (bug 24575). Incidentally, the submitter still hasn't said where he clicked in order to see this behavior. I kept the bug open because Trudelle asked me to, but I really don't know what the bug is, whether it's a dup of 24571, or what else might need to be fixed until I know exactly where he was clicking.

Same problem under Linux (Build ID 2000022108) Scrolling the scrollwheel moves the page up/down and all is well. But clicking anywhere on the page with the scroll-wheel button will paste whatever is on clipboard to the URL field. If the word in clipboard was "wrongword", mozilla will try and auto fill out http://www.wrongword.com - and of course the page does not exist. CLicking the back-button on browser does not help to take you b ack to the previous page either - cause then the word "wrongword" will just reappear in the url-field, and mozilla yet again tries to "guess" the url. If it's intentionally designed like this - that middle-click will paste "clipboard content" to urlfield, regardless of where the cursor was on the webpage - that is a handicap de luxe. The middle-click should only activate a paste when the cursor is over the URL-field!

I like how most other Windows apps work, which is if the mouse wheel is clicked on the window, it activates that window. This is currently quite handy in NS 4.x, as with pages with frames you have to activate the frame that you want before you can scroll it with the mouse button. Since my finger's already on the mouse wheel, it's easiest to click the window with that.

The submitter still hasn't replied -- I have to assume that he was indeed talking about the functionality of middle click in page content going to that page (which of course also loads the urlbar). Making that a pref is covered by bug 24571, so I'm duping. (I may end up taking 24571 myself, but that's a different issue; it doesn't help to have two bugs open on the same issue.) *** This bug has been marked as a duplicate of 24571 ***

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

Sorry for the spam. changing qa contact.

Verified duplicate.