Closed Bug 25295 Opened 25 years ago Closed 25 years ago

Intellimouse "wheel click" and Clipboard bug

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 24571

People

(Reporter: slash, Assigned: akkzilla)

References

(
URL
)

Details

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...
Component: Browser-General → XP Toolkit/Widgets
*** Bug 25525 has been marked as a duplicate of this bug. ***
Assigning to default owner.
Assignee: nobody → trudelle
QA Contact: nobody → paulmac
*** 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.
Assignee: trudelle → akkana
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 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Adding dependency for the bug on adding a pref.
Marking M15 because that's what 24571 currently is.
Status: REOPENED → ASSIGNED
Depends on: 24571
Target Milestone: M15
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 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
No longer depends on: 24571
Resolution: --- → DUPLICATE
*** Bug 25574 has been marked as a duplicate of this bug. ***
Sorry for the spam. changing qa contact.
QA Contact: paulmac → jrgm
Verified duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.