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)
Tracking
(Not tracked)
NEW
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
Reporter | ||
Comment 1•23 years ago
|
||
(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.
Comment 2•23 years ago
|
||
-> 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
Reporter | ||
Comment 3•23 years ago
|
||
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
Comment 5•23 years ago
|
||
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 → ---
Comment 6•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
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
Comment 10•23 years ago
|
||
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.
Comment 13•23 years ago
|
||
Might be a dup of bug 64577, "middle-click (to open link in new window) doesn't disable scrollwheel".
Updated•23 years ago
|
Target Milestone: --- → Future
Reporter | ||
Comment 14•23 years ago
|
||
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?"
Comment 15•23 years ago
|
||
*** Bug 106066 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
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
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Updated•17 years ago
|
Assignee: bross2 → guifeatures
QA Contact: bugzilla
Comment 17•16 years ago
|
||
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
You need to log in
before you can comment on or make changes to this bug.
Description
•