Intellimouse "wheel click" and Clipboard bug




18 years ago
18 years ago


(Reporter: slash, Assigned: Akkana Peck)


Windows 2000

Firefox Tracking Flags

(Not tracked)





18 years ago
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" and it displays an error message "www.Netscape was first, 
and Netscape will be could not be found.  Please check the name and 
try again."

The debug output is follows:

->>>>>>>>>>>>>> Read Clipboard from memory
->>>>>>>>>>>>>> Write Clipboard to memory
->>>>>>>>>>>>>> Read Clipboard from memory
URL on clipboard: 'http://www.Netscape was first, and Netscape will be
'; length = 61
FindShortcut: in='http://www.Netscape was first, and Netscape will be'
Error loading URL http://www.Netscape was first, and Netscape will be

Document: Done (0.08 secs)
Move window by 309,149.6
screen x 0screen y 0

Comment 1

18 years ago
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...
Component: Browser-General → XP Toolkit/Widgets

Comment 2

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

Comment 3

18 years ago
Assigning to default owner.
Assignee: nobody → trudelle
QA Contact: nobody → paulmac

Comment 4

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

Comment 5

18 years ago
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.
Assignee: trudelle → akkana

Comment 6

18 years ago
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

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 ***
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 7

18 years ago
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?

Comment 8

18 years ago
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.

Comment 9

18 years ago
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.

Comment 10

18 years ago
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).

Comment 11

18 years ago
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.

Comment 12

18 years ago
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.
Resolution: DUPLICATE → ---

Comment 13

18 years ago
Adding dependency for the bug on adding a pref.
Marking M15 because that's what 24571 currently is.
Depends on: 24571
Target Milestone: M15

Comment 14

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

Comment 15

18 years ago
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.

Comment 16

18 years ago
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 - 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!

Comment 17

18 years ago
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.

Comment 18

18 years ago
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 ***
Last Resolved: 18 years ago18 years ago
No longer depends on: 24571
Resolution: --- → DUPLICATE

Comment 19

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

Comment 20

18 years ago
Sorry for the spam. changing qa contact.
QA Contact: paulmac → jrgm

Comment 21

18 years ago
Verified duplicate.
You need to log in before you can comment on or make changes to this bug.