Open Bug 88820 Opened 23 years ago Updated 3 years ago

Clicking and spinning the mouse wheel when not on a link opens a window and then loads the url in the current window

Categories

(SeaMonkey :: UI Design, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

Future

People

(Reporter: david.hagood, Unassigned)

References

Details

I've found a case where the middle mouse button works incorrectly.

If there is data in Mozilla's copy/pase buffer, and
If the middle mouse is clicked over a section of a page that is not a link,
Then the following things happen:
   1) the contents of the copy buffer are placed into the URL field of the
current window, and
(let my try to finish this...)
 1) the contents of the copy buffer are placed into the URL field of the
current window, and

 2) the current window is sent to the resulting URL, and no new window is created.

I get this a lot because I have a scroll-wheel mouse that sometimes jumps a
click on the scroll wheel when I press the wheel, which causes the page to
scroll before Mozilla gets the click, and causes the mouse to not be over a link.

I would think that clicking the middle mouse button over dead space should have
the same effect as clicking the left button over dead space: nothing.


To recreate:
Mark some text in a window. Preferably, this shouldn't be a link.
Move the mouse to a dead region of the window.
Click middle button.
-> ui design.  This is how other browsers work on Linux, but I remember a 
discussion a while ago where someone suggested making the middle mouse button 
go into autoscroll/panning mode on all platforms.  I like that idea, but mostly 
because I dislike Linux's transient clipboard in general.
Status: UNCONFIRMED → NEW
Component: Browser-General → User Interface Design
Ever confirmed: true
May I then suggest that the "middle button=paste contents into URL" only happen
when the click occurs in the URL field? If I want to do the X Windowing system
standard "middle button=paste selection" to move to a new page, I'm going to do
the paste into the URL bar, not into the main window.
this is prefable, just disable it.  i expect in the future most people will 
indeed disable this whacky feature because we'll have panning support.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Exactly.  So you shouldn't have to go to your prefs to get panning to work, just
because you happen to be a Linux user.  Having prefs can be useful, but having
sane defaults is important.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Really -> UI design
Assignee: asa → mpt
Status: REOPENED → NEW
QA Contact: doronr → zach
but panning doesn't exist yet. and if we get rid of this default we'll get 
quite a few nc4unix 4xp bugs. - personally i think this default is silly, i 
just don't want the bugmail.
Yes, once we have panning, middle-click-in-the-content-area should go away, 
replaced by middle-click-in-the-address-field.
Component: User Interface Design → XP Apps: GUI Features
Depends on: Autoscroll
jag for is it possible to make the behavior atomic?
Assignee: mpt → jag
QA Contact: zach → sairuh
Summary: Clicking middle mouse when not on a link works incorrectly → Clicking and spinning the mouse wheel when not on a link opens a window and then loads the url in the current window
Erh... Is the summary correct? Looks like the complaint is that something 
unexpected happens when you accidentily scroll your page when trying to 
middle-click with a scrollwheel mouse.

In my opinion, the "old" behaviour shouldn't go away. Make it a pref to switch 
between panning, load url, and do nothing. Preferably without a UI.

I use "middle click in content to load url in clipboard" a lot. The content area 
is a much larger area to click on than the address field, hitting the content 
area on average requires less effort than hitting the address field.

On another note, IE does the panning thing when you middle-click on a link. The 
reporter's complaint is that he tried to middle-click on a link (to open it) but 
accidentily scrolled the page while trying so. If we change our behaviour to 
match IE's, the whole point is moot, because then you won't run into this 
problem anymore, since you'll just need to do right-click -> Open Link in New 
Window.

Not sure if the reporter would like that solution ;-)

But anyway, two suggested work-arounds:
1) use right-click -> Open Link in New Window
2) add this line to your prefs.js:

user_pref("middlemouse.contentLoadURL", false);

Until such a time that we add support for middle-mouse-click-pans and we'll need 
to give you a way to support middle-mouse-click-opens-link-in-new-window.
i don't have a mouse with a scrolling wheel, so...
Keywords: qawanted
-> blake
Assignee: jag → blakeross
Might be a dup of bug 64577, "middle-click (to open link in new window) doesn't 
disable scrollwheel".
Target Milestone: --- → Future
it does sound like a dup of bug 64577, however I see a problem with the proposed
solution of disabling the scroll wheel during a button-down event.

The timing relation of the two events (scrollwheel event and middle button
event) is somewhat dependant on the hardware - my mouse will sometimes click
over on the scroll wheel before the middle button switch actuates, sometimes
after. You'd almost have to time-delay any button event (scroll wheel or middle
button), then evaluate "Did I see any other events during this time?" 
*** Bug 106066 has been marked as a duplicate of this bug. ***
I am removing bug 22775 as middle clicking during wheel scrolling will still 
have an undesirable effect. If you middle click when wheel scrolling in that 
case, it will bring you into autoscroll mode. Therefore, the changing role of 
the middle mouse button is not enough of a solution.

Its true that normally the next mousewheel scroll will turn off autoscroll, 
except if its done accidentally after the last scroll. Then, autoscroll will 
be activated and when you move the mouse, the page will scroll unwantedly.

I think the best solution is to wait a certain amount of time before accepting 
middle mouse clicks. I'm not sure whether we should do this at the widget code 
level or within nsEventStateManager or whatever. I also think it should be 
fixed independently of autoscroll as eventually people might be able to 
reassign the trigger for autoscroll. 

It is something to think about, though, and probably fix during the creation 
of autoscroll, and therefore, I am marking it as blocking bug 63712.
Blocks: 63712
No longer depends on: Autoscroll
Product: Core → Mozilla Application Suite
Keywords: qawanted
Assignee: bross2 → guifeatures
QA Contact: bugzilla
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.