Closed Bug 63712 Opened 24 years ago Closed 19 years ago

How to activate AutoScroll/Panning on various operating systems?

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: timeless, Assigned: netdragon)

References

(Depends on 2 open bugs,
URL
)

Details

(Whiteboard: [windows mouse driver issues?])

Attachments

(2 files)

The Hand explained
5.98 KB, image/jpeg
Details
mousetest.exe for testing activation on windows
140.00 KB, application/octet-stream
Details 
This bug is split off from bug 22775.

Once that feature is implemented we will need actual triggering mechanisms.

The following have been mentioned and others should be mentioned in this bug.
* Mousewheel Click (one of the standard methods from IntelliMouse on win32)
* Middle Button Click (unix mice tend to have three buttons and the middle only 
has a minor binding for links to open in new windows) -- Default behavior here 
would be to pan unless clicking on a link in which case the link behavior 
overrides.
* Command+click (on Mac OS) to behave like middle button click.
* Scroll Lock. Pressing this will place the Artifact at document center with 
cursor at the same, arrows or mouse will move cursor.  Escape, Scroll Lock, 
maybe Enter and probably clicking will exit the mode.  If possible, the Scroll 
Lock indicator should be cleared if we exit by some other means, and assuming 
no one objects we should toggle it for the other entry mechanisms.  Objections 
should be placed in a specific bug blocked by this one.
Depends on: Autoscroll
Netscape nav triage team: as per Alec Flett's pre-triage recommendation, this 
bug is nsbeta1-.
Keywords: nsbeta1-
Whatever method we choose, it has to be compatible with both panning and 
autoscroll. IE: If you persist on this method (ie hold down on the middle mouse 
button as one possibility) then it pans, if you just momentarily do it, then 
you autoscroll. 
Marking nsbeta1- bugs as future
Target Milestone: --- → Future
Brian, weren't you working on this?  Do you want to take it?
Sure
Cool, thanks. Reassigning...
Assignee: ben → boberb
Ok, there are two phases that need to be done.

Phase 1: Basic Autoscroll/Panning support. This will occur starting now and 
ending when Autoscroll/Panning is moved into the tree. Basically, there will be 
one way to access Autoscroll/Panning on each os. i.e., for Windows it is 
already decided to use the middle mouse button. Once basic autoscroll/panning 
is implemented on each os, it will be released into the tree, and phase 2 will 
be started.

Please start talking about this now!!! If you don't, I will just use the middle 
mouse button for each os temporarily until you come up with a solution.

Phase 2: Prefs-guided autoscroll/Panning. This really should be done before the 
release of Mozilla 1.0. There will be a set of choices in prefs for what the 
triggers are for autoscroll/panning for each os. i.e.: on windows, for the rare 
person that doesn't want to use the middle mouse button, they can choose some 
keystroke or something.

The support for other oses needs to be written by other people. I can only do 
the Windows support. Adding other os support will be easy. All they have to do 
is call one of two mouse messages. It will probably require 15 lines of code at 
most for each os, plus code to do the pointers.
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9.3
Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
These comments were posted in bug 22775, but I was flamed by a person (who will
remain anonymous) and reminded that the comments should have gone in this bug
instead:


------- Additional Comments From P P 2001-07-24 06:27 -------

Clicking mousewheel interferes with 'Open in new window' where clicking wheel is
considered middle mouse button click. This makes this kind of scrolling unusable
while cursor is over hyperlink. See issue# 85169.


------- Additional Comments From Alex Bishop 2001-07-24 11:34 -------

That could be fixed by making the mousewheel only open a link in a new window
when the wheel is released (if it doesn't do that already - I can't recall) and
making the autoscroll/panning occur if the mouse is moved before the wheel is
released (obviously it would be able to move a little bit and still trigger the
link in the same way that the mouse can be moved slightly between the clicks of
a double-click).


------- Additional Comments From P P 2001-07-25 07:56 -------

Oh - IMHO this would be terrible solution. I don't want to care when should
I release the button, how or when to move, where the pointer is at the moment
and so on... I'd like to see the behaviour that is in Internet Explorer.
There should also be an option on disabling 'New window' via middle button
click, that would solve this interference.
There is still discussion on this one going on, should we push it out to another
milestone?
I was going to wait until the feature was in, then work on activation problems
as they appeared.
Pushing back. This isn't necessary before putting in support for other oses 
before windows. We can probably assign it something temporary. Please discuss 
what the best solution would be for every os.
Target Milestone: mozilla0.9.4 → mozilla1.0
Depends on: 103808
I don't understand this bug.  I already have autoscroll in Galeon (embedded
Mozilla) via some silly javascript functions.  There are four different auto
scrolling speeds.  The original implementation is here:

http://www.bookmarklets.com/tools/look/index.phtml
Middle mouse in content area does a bunch of other things on linux/unix besides
opening links in new windows, like pasting to form elements, or going to the url
in the X selection.  It's not a "minor binding" and a lot of people would miss it.

But those are all things that could be bound to button up rather than button
down; Alex Bishop's solution would be okay at least for many users (obviously P
P disagrees, though).
I agree.  Just don't initialize the autoscroll action if the pointer is over a
text widget or URL.  Is this not possible?
It's easy to tell what's under the mouse when a mouse action happens (that's how
the current JS middle mouse code works).  But middle mouse means something even
in general content, so we'd have to trigger on mouse up vs moved-while-down at
least in that case.
> But middle mouse means something even
> in general content, so we'd have to trigger on mouse up vs moved-while-down at
> least in that case.

...doesn't sound too good to me. A nice, safe feature like autoscrolling
combined with a destructive thing like jumping to an url being bundled that
close would make the scrolling feature a bit difficult to use, especially for
slow scrolling speeds, where you'd only move the mouse a little. So I think that
autoscroll and content-area-middle-click-paste-opens-url should be mutually
exclusive prefs, and no effort should be wasted on implementing both at the same
time on the same area with the same button, and the scrolling feature access
should preferably be identical across platforms.

As it happens, I filed rfe bug 111337 a while ago, thinking that
middle-mouse-paste-opens-url is useful still... just that it should happen in
some specific place in chrome, not all over the passive parts of the document
you're viewing.

This is not a 1.0 blocker according to
(http://www.mozilla.org/roadmap/mozilla-1.0.html
Work on this bug will continue but it will not be checked in until
after 1.0
Target Milestone: mozilla1.0 → mozilla1.0.1
Hi all.  I was referrred to this bug for possible comment, and of course I have
one :)

AUTO-SCROLLING: IMO (!!!), after reading all of the previous comments, to make
this feature more standard across platforms in Mozilla, and to make it easier to
differentiate from other mouse functions, we should use a modifying shift key
which could be set in prefs (<Shift>, <Ctrl>, <Alt>, combination thereof, or
some key which must exist across all platforms (will require some research) +
middle button (wheel button) in Windows and whatever mouse button in other OS's.

In addition, IMO, I have strong questions about whether implementation of manual
scrolling (holding down mouse button) is necessary, unless it already exists in
Mozilla or NS.  Auto-scrolling is a bit more cumbersome, but achieves the same
result.  Maybe if it *is* implemented, it could be with a different mouse button
but the same modifying shift key.

Brian: I would be glad to test your code.  If you could put it in a test
program, even with just a target in the middle of a Windows window with a text
file, or whatever is easiest, that would work fine.

I also (please don't anyone flame me for tossing out this idea) wonder if long
lists of comments on an important (I think) feature is not the optimal way of
discussing this intelligently.  Maybe we could, just for this feature, set up
some kind of private e-mail list with the strongest security available at
topica.com or yahoo.com and maybe a private chat room where we could meet at
certain times, like once a week.  Please don't yell at me for this idea.  These
resources are out there just waiting to be used, although I don't normally use
chat rooms.  Seems like Chris Pirillo of Lockergnome uses them to great
advantage, as well as guest speakers in other places.

Caveat:  Please feel free to ignore anything in this comment you don't like :)
Steve
Steve: On IE both holding down and dragging and releasing and moving the mouse
accomplish the same thing - which I think is what you were referring to. But on
Mozilla, releasing and moving the mouse will have a behavior similiar to IE,
while holding down and dragging will let you act as if you are holding down on
the scrollbar tab. The thing is, it will let you act as if you are holding down
on the vertical and horizontal tabs at the same time. 

For the modifying key (if used) then it should be possible to choose none in
prefs, since in Windows just using the middle mouse mouse button is the standard
way to access this behavior in applications.

There haven't been a flood of comments yet that would warrant bringing this
somewhere else, but I think we need to evaluate how we are gathering people's
input as this could really get lengthy as more people become aware of this and
it nears completion. 

For now, we need more peoples' opinions and I'm going to post something to the
newsgroups.

Its best to keep the access method OS-specific, and I have set it up so that is
possible. Possibly, some OSes will have the same methods, but trying to have it
the same on all OSes will just be a mess. For instance, the shift method will
annoy Windows users.

Also, we should keep in mind that not every mouse has a middle mouse button.
(Especially on Mac where they seem to think that all people need is one button :-)

Mac - Control click?
Win32 - Use the standard middle click
Linux - Middle click or shift-middle click (look at bug 88820)
OS/2
AIX
Solaris
Irix
FreeBSD
Alpha
Hpux

I don't know of any other program which offers prefs for which modifier key
triggers panning. That would be truly daft -- tossing a coin would be more
usable than offering a pref. (And please don't sign me up for any
mozilla-mouse-panning-general mailing list, either.)

Ok. Where the mouse has a middle mouse button, the middle mouse button should
trigger autoscrolling/panning, like it does in any other program which has this
feature. Scrolling is much *much* more common than pasting is, so
middle-mouse-go-to-whatever-the-selection-was will have to go away. This is a
non-dangerous change (apart from the danger of me getting flamed by Akkana and
co. -- I'm *really* sorry!); expecting a Go and getting panning would only be
mildly annoying, whereas expecting panning and getting a Go would run the risk
of dataloss if the current page was not cached.

Naturally you also need a modifier key for those mice which don't have a middle
mouse button, or those which (as on the Mac) are so advanced that they don't
need buttons at all. Start from two assumptions:
(1) Auto-scrolling (modifier+drag) and panning (modifier+click) should use the
    same modifier key.
(2) It should only be a single modifier key, otherwise it'll be so awkward it
    would have been quicker just to use the scrollbars instead.

Process of elimination for Mac ... You can't use Shift, because Shift+click and
Shift+drag are for extending a selection. You can't use Control, because both
Control+click and Control+drag are for opening the shortcut menu. So you're left
with either Option or Command. The only Mac app I know of with a modifier key
for some sort of scrolling is MSIE, which uses Command+drag for grab-scrolling
(much less useful than pan-scrolling!), and which we're trying to win users
from. So, let's do Command+drag for auto-scrolling/pan-scrolling.

Process of elimination for the PC ... You can't use Shift, because Shift+click
and Shift+drag are for extending a selection. So you're left with either Control
or Alt. Control is easier to hit in the likely event that your hands weren't on
the keyboard when you wanted to start scrolling. And (minor reason) it'll be
consistent with the Mac modifier -- `accel', in Mozilla parlance, for both. So,
let's do Control+drag for auto-scrolling/pan-scrolling.
steven has kindly volunteered to test this out on win32.

when this is fixed, i might be able to find a mac or linux box with a
mousewheel. but if there's someone else who has such a setup, that'd be swell!
Keywords: qawanted
QA Contact: sairuh → groginsky
Depends on: 111337
QA: I confirm wheel scrolling up/down with Intellimouse 12A in build 2002022703
on win98se.  That is all that is happening in this build.

Brian: it would be helpful if you could let me know when you add code so I can
test it.  My e-mail address is groginsky@yahoo.com

Thanks.
Brian: better yet, just mention code additions to the pool here.  Uh, please
disregard my last comment.
Just wanted to add my $0.0005.  I've read the preceding comments, and as a
regular Joe user, I really hope this gets fixed soon (1.0).  The only thing
preventing me from switching my default browser to Mozilla right now is the lack
of middle mouse scroll.

Regarding comments #19, #21, I'm not sure if I understood correctly, but I think
it would be very bad for the default behavior to require a control key to be
pressed to access mouse scrolling.  If I have to reach for the keyboard to
scroll, I might as well forget about the middle mouse and reach for the keypad
or page up/down.
Jason: at least with comment 21, you would be able to trigger autoscroll by 
Ctrl+clicking /or/ middle-clicking in a blank area of the page.  That would
match Mozilla's existing behavior for links, which treats both Ctrl+click and
middle-click as "open link in new window".
*** Bug 133054 has been marked as a duplicate of this bug. ***
Attached image The Hand explained — 
Mozilla should also feature a hand for scrolling through webpages.
With the hand it's possible to grab the page and move it around.
chibi: that issue goes in a seperate bug. Please search for such a bug, and if
it exists, CC me. If it doesn't, file one and assign it to me. Thank you.
Hmmm, true that there is another bug for the implimentation of Acrobat style
dragging (whose number I don't know off the top of my head), but the solution as
to how it is activated could be inherently similar.
For example, I believe a good solution to the issue of activation would be for
down-middle-click + drag to activate the grabbing of the screen and
down-and-up-middle click + move to activate the scrolling of the screen.
If discussion of the two methods of activation is kept separate it could lead to
complications either in method similarity, dissimilarity or coding.

P.S. "Mouse Drag" is also a part of the summary of this bug, which could seem to
indicate that activation of "grabbing and dragging" the screen is a part of this
bug.
adding self to cc list
I used to use the middle button for autoscroll but now that it opens links in
new windows I'm hooked on it. I just use the scroll wheel now (and wish I could
enable new links on NS4). I don't know about others but the "link in new window"
option is a real selling point for not only myself but for several people that
I've encouraged to try Mozilla.

Perhaps using Left Click + Right Click for the autoscroll instead could work...?
Some people I have talked to said they would like autoscroll/panning, but would
like the middle mouse button to be a preference.

When we get to that point, we should file a bug to add the preferences imho
before checkin.

re: bug 133054 - I see no point in not doing the hand dragging at the same time.
Actually, a few people expressed that they wanted that on bug 22775. IMHO, bug
133054 is not a dupe of either this bug or bug 22775. One issue per bug,
therefore, I think that bug 133504 should be reopened. What does everyone think?
*** Bug 103521 has been marked as a duplicate of this bug. ***
*** Bug 156061 has been marked as a duplicate of this bug. ***
Blocks: 154479
Here is mousetest.exe that I made a little while ago - It can be used to test
if the middle mouse button is being sent to the application or being stolen by
your mouse driver.
Dave Booth's comments in bug 22775:

Regarding whether it will apply to all logitech devices with the new drivers, I
have no idea. If the new drivers support your old mouse I'd guess it would. I've
just installed them for the old logi trackball I use on my NT box here at work
(one of the original logi marbles - early rev of the teardrop-shaped two-button
one, ps2/serial, before they introduced USB as an option. Its at least 3 years
old.) That ones going to be interesting - it doesnt even have a middle button
but it does have all the options to change each buttons functionality that I see
on my 4-button device at home. I'll set up button2 as "middle" and then change
it to activate autoscroll and see what your mousetest.exe reports on that
machine in each case. Its about time that windows box earned its keep anyway - I
spend most of my day on this solaris machine and avoid the PC whenever possible :)

...

ok, results from mousetest with the logi drivers... 

First some extra info: There are 3 ways to enable scrolling in these drivers
(mentally picturing Brian tearing his hair out at this news) but fortunately
only 2 of them are an issue here. The one we can ignore is implemented by the
"scroll bar (horizontal)" and "scroll bar (vertical)" button assignments. These
appear to function by warping the pointer to the appropriate scroll bar thumb
and engaging draglock whilst restricting the pointer to moving in the relevant
dimension. A second click releases draglock and warps the pointer back to its
original position. These settings have no effect on windows without the selected
scrollbar. The two other ways of scrolling are named "autoscroll" and "universal
scroll" respectively. Each has a checkbox for "use MS-office compatible
scrolling only" that changes its behaviour (most notably restricts it to NS
scrolling, whether the window is scrollable in both directions or not so its of
limited usefulness!) Autoscroll is where they display an artifact at pointer
position and scroll in the direction you move, scrolling faster the further away
from the artifact you move the pointer. Universal scroll is where they just
display the artifact and mouse movements scroll the window directly (possibly
their analogy for wheel function?)

Scenario 1: vanilla config. Setup is button 1 & button 2 default functions and
both emulates middle. Exactly as expected, mousetest reports positions and
buttons exactly as set in the driver. button 1 -> L, button 2 -> R, both -> M.

Scenario 2: Change button 2 to be middle-click, set both to be right-click.
Mousetest results change with reassignment of buttons. button 1 -> L, button 2
-> M, both -> R. Proves modification of messages in driver :-/

Scenario 3: Set button 2 as autoscroll. Check autoscroll option to "use
ms-office compatible scrolling only" Button 2 is reported as middle button.
Artifact is not displayed.

Scenario 4: Same as 3 but without checkbox selected. Button 2 not reported at
all - artifact displays and cursors change. When artifact is visible, mousetest
does not see any change in mouse position.

Scenario 5: Set button 2 as universal scroll. Check option to use ms-office
compatible scrolling only. Mousetest does not report button 2 at all, artifacts
display, mousetest does not see any mouse movements whilst artifact is visible.

Scenario 6: Same as 5 but without ms-office option. Results same as 5.

Just to be certain, I loaded mozilla and set up custom wheel behaviour then
looked to see if any of these scenarios made the lizard respond as if to a
mousewheel. Results were uniformly negative, therefore whatever changes these
drivers are making they are not sending wheel events at any time. They probably
would if my device actually HAD a wheel, but its not part of the customizable
options.


...


More logitech data.. I grabbed a download of winspector and have been poking
around the UI with the logitech scrolling.

my "test app" was moz 1.1, "test pages" were the mozilla.org start page and the
bugzilla query page.

I also played with other apps to look for behaviour differences.

MS-like autoscroll (office-compatible checkbox on): Does nothing for mozilla or
any other app but send middle button events. Its therefore reasonable to assume
that any app other than those specifically coded to autoscroll in response to
the middle button will not respond to this. Under these curcumstances the NSEW
artifacts etc must be explicitly added to the app. This breaks autoscroll for
almost every app other than MS products.

Logitech autoscroll (office-compatible checkbox off): Works (sorta) for pages in
mozilla provided there are no scrollable subwindows - like the list boxes in a
bugzilla query, for example. Displays artifact by creating a window of class
"Logitech ScrWnd" (presumably the artifact itself) at the cursor position which
then grabs the focus, changes the cursor and sends SBM_SETSCROLLINFO messages to
the scrollbars of the previously-focused window to move its contents around.
Seems to never really detect a horizontal scrolling capability in mozilla, even
if there is a horiz scrollbar in the main window so only ever shows the NS
artifact and cursors. NS scrolling works as expected though. The problem here is
that if there are scrollable subwindows (the bugzilla query page is a good
example) the scrollbar that gets the SETSCROLLINFO messages is usually the one
attached to the nearest listbox to where the artifact is displayed. Mozilla is
unique in this behaviour. If I do the same thing in IE the "right" scrollbar is
moved. Other windows with scrollable widgets also behave as expected. The "real
window" scrollbars get these messages, not scrollbars attached to a contained
widget.

universal scroll (checkbox doesnt seem to make a difference): never touches the
main window, only time you see any scrolling effect is if there are scrollable
widgets. Scrolls the widgets not the main window. Again displays artifacts by
creating a window at cursor position that grabs the focus and sends events to
scrollbars. Works just fine in any other app though. 

This looks very much like the logitech drivers are quite capable of scrolling
mozilla as-is, so long as they send their events to the right component of the
right window. The only real difference I can find to explain it is that the
structure of the widget sets and window components are completely different for
mozilla to every other app... I'd presume that this is due to mozillas
cross-platform heritage. The logitech drivers seem to be relying on certain
win32-specific window styles that are not strictly relevant to the object model
and widget sets used in mozilla. 

Hate to say it, Brian, but this one looks like its gonna hurt....


Adding whitespace question about windows mouse drivers issues to remind us.
Whiteboard: [windows mouse driver issues?]
>Dave: thanks for the research. Can you research how we can override the
Logitech >behavior for scenarios 4-5?

>Scenario 4: Same as 3 but without checkbox selected. Button 2 not reported at
>all - artifact displays and cursors change. When artifact is visible, mousetest
>does not see any change in mouse position.
>
>Scenario 5: Set button 2 as universal scroll. Check option to use ms-office
>compatible scrolling only. Mousetest does not report button 2 at all, artifacts
>display, mousetest does not see any mouse movements whilst artifact is visible.
>
>Scenario 6: Same as 5 but without ms-office option. Results same as 5.

Looks like after implentation of bug 22775, we will have to deal with scenario
4,5, and 6. There might be a way to override it or there might be a way to
process some messages and return false or something.

>Scenario 3:
>MS-like autoscroll (office-compatible checkbox on): Does nothing for mozilla or
>any other app but send middle button events. Its therefore reasonable to assume
>that any app other than those specifically coded to autoscroll in response to
>the middle button will not respond to this. Under these curcumstances the NSEW
>artifacts etc must be explicitly added to the app. This breaks autoscroll for
>almost every app other than MS products.

Or applications not using Microsoft widgets. I wouldn't say breaks for every
application other than those, but makes it so they have to implement it
themselves as we are. If it is checked, everything is fine.

>universal scroll (checkbox doesnt seem to make a difference): never touches the
>main window, only time you see any scrolling effect is if there are scrollable
>widgets. Scrolls the widgets not the main window. Again displays artifacts by
>creating a window at cursor position that grabs the focus and sends events to
>scrollbars. Works just fine in any other app though. 

That is because our widgets such as text-box are windows controls afaik.

>This looks very much like the logitech drivers are quite capable of scrolling
>mozilla as-is, so long as they send their events to the right component of the
>right window. The only real difference I can find to explain it is that the
>structure of the widget sets and window components are completely different for
>mozilla to every other app... I'd presume that this is due to mozillas
>cross-platform heritage. The logitech drivers seem to be relying on certain
>win32-specific window styles that are not strictly relevant to the object model
>and widget sets used in mozilla. 

Right - if we process those messages. This would make the autoscrolling
different, though, when using this feature than in normal cases. I don't know if
this is the behavior we want. Although its true we want Mozilla to do things in
that are consistent on the OSes, Logitech scrolling is not the most common (as
not everyone uses it). Also, it would look and feel different in the MS scroll
and the Logitech scroll case. This would create an inconsistancy within Mozilla
on Windows. Since we are porting this to multiple OSes and will be providing the
behavior ourselves there, I think we should try to override the Logitech
behavior. Maybe if we respond to the notification with "FALSE" or something it
won't be done by Logitech.
We might be able to somehow put in a hook on the driver too.
Followup...

The ms-compatible scrolling options in a logitech driver are, as Brian correctly
points out, supposed to need functionality within the app to support them. Not
sure why the "universal scroll" (panning?) incarnation looks to be functional
whether the app-side support functions are there or not... 

The other scrolling options (without "use MS-office compatible scrolling only"
checked) are supposed to extend this functionality to apps that otherwise
wouldnt support it. These implementations get data on the focused window when
activated and scroll by sending SETSCROLLINFO messages to its scrollbars. In
general it works pretty flawlessly *provided* the app uses the native widget
set. Mozilla, of course, doesnt. It actually works as designed here too, but the
widgets built with mozilla appear to the logitech drivers as full-featured
windows rather than "mere widgets" and so when the enhanced functions of the
driver are triggered, mouse movements scroll the widget, not the main window.

I can see and fully understand all the arguments for implementing the
app-specific scrolling support. MS pointing devices tend not to do it any other
way, it also allows pointing devices without enhanced drivers to work. Looking
exclusively at the windows world, where there are pointing devices with more
than two buttons on them Microsoft and Logitech probably account for the vast
majority. I'd therefore suggest we take care of both, without requiring users of
Logitech devices to turn off useful features. I cant call this behaviour in moz
a bug per se.. if I have to deprive some other apps of autoscroll functionality
to have it present in mozilla, the lizard will probably win.

Its just my sense of neatness that rankles at the "right" events reaching the
app (for proper scrolling with current code) but rolling down to some window
control at the far end of the apps window tree instead of being bubbled up to
the main client window as they arguably should... kinda like happened with the
wheel code. 

I'm going to carry on looking at this as I can - see if I can come up with a
coherent understanding of exactly whats going on and possibly a suggestion or
two as to how to make the "generic" solution work without breaking things that
are central to the mozilla ethos (like cross-platform similarity and important
stuff like that) I'll probably never manage to be coherent enough in the C++
stuff to actually code it but I'll call it a success if I can get close enough
that a real coder can read it and say "oh, thats easy.. you just do this..." :)
Dave: I'm not really going to look at this issue until bug 22775 is fixed, but 
what I recommend you do is write a dummy Frame/view application using MSVC++ 
6.0 and MFC that works properly with the logitech drivers because it uses 
native stuff, etc. Then, using whatever documentation you can and/or studying 
the messages, try to block the Logitech drivers from having any affect on the 
application in the last 3 cases. Even if you don't understand the Mozilla C++ -
 doing what I mentioned here requires a lot less knowledge. Once you figure 
out how to block the messages, you can tell us how you did it. You will 
probably have quite a while to do this.

I recommend looking for some information on the Logitech APIs/etc's innards 
and how applications can interact with it. This could include API functions, 
ways to hook the drivers, and ways to block actions using windows messages.

Thanks for your help. Give an update when you have found out anything helpful.
I also noticed this problem with the IBM Thinkpad trackpoint drivers. It has 
been sitting there right under my nose all this time too ;-)

If you reassign the center button on the IBM Thinkpad 600E to scroll, then the 
app doesn't recieve the middle mouse clicks.
Depends on: 174495
This bug isn't about a hand tool. That is bug 133054. Therefore, this bug 
doesn't block bug 154779. I also added bug 174495 about the issue presented by 
David Booth with built-in mouse software such as Mouseman and Trackpoint.
No longer blocks: 154479
Summary: [RFE] How to activate "AutoScroll"/Panning? Mousewheel Click; Mouse Drag; Middle Button Click; Scroll Lock → [RFE] How to activate AutoScroll/Panning on various operating systems?
Depends on: 88820
Sorry. I meant bug 154479 in the last comment.
Blocks: Autoscroll
URL: http://mozscroll.mozdev.org/
No longer depends on: Autoscroll
Summary: [RFE] How to activate AutoScroll/Panning on various operating systems? → How to activate AutoScroll/Panning on various operating systems?
well, this bug has been open for just over 2 years now [ bug 22775 ], and theres
still nothing to show for it. Brian Bober may be a NetDemon, but hes certainly
no SpeedDemon. 

galeon [ http://galeon.sf.net ], a browser based on mozilla, has since 
implemented this feature beautifully. If you have a recent version
available, goto Settings->Preferences->User-Interface->Mouse and select 
"Enables auto-scrolling" from the middle button action option.

Since this bug opened in October 2000, all Mr Bober has offered is a few 
images and an empty project page, that frankly any idiot could have whipped
up in 10 minutes in Xpaint. Where are the patches ? 

During its 2 years, many people have asked Mr Bober to step down and make way 
for someone who is capable/interested/whatever of actually doing something
about this, yet he maintains hes working on it. With sporadic and meaningless
status updates, this just isnt good enough.

Brian: many people are interested in getting this working, Ive been waiting
for this feature, the only "blocker" is YOU. damnit, get out of the way, and 
let somebody else actually get this implemented. I can see at least 4 comments
on this bugs *3* pages offering to take this off your hand, and i would also
be interested in doing some work on this. 

So what excatly are you going to do ?

Flame me all you like, but i'll bet a lot of people agree with me.

Jason, your comments are entirely inappropriate and they indicate that you have
no idea whatsover of how mozilla works.  Having this bug assigned to himself
gives no coding privelage or inside information to Brian.  If you would like to
fix this bug, make a patch and post it.  Otherwise, keep your whining and
insults to yourself.
newsflash ben, this guy has been working on it for _2 years_ its entirely
possible that im mistaken and hes been working his ass off for the whole period.
Would it be appropriate for me to start working on this now without comment from
brian ? i dont think so.

i mean, im not asking for blood here, all im asking for is a progress report, a
patch, a ChangeLog, a snapshot of his source tree, a screenshot, summary of
research done anything! just a smidgen of evidence that he hant been sitting
around for 2 years with his dick in his hand.

i cant see what the problem is, i could have written the patch in brainf*ck and
had it compiling on hp/ux in 2 years, but if there are huge issues involved,
lets hear them. 

I think brian is taking the p*ss, and i want to hear a response. 

If you want info from Brian, try emailing him personally.  Even better, email
him with insults and threats.  That will really get you a quick and courteous
response.  

You need to remember that this is a volunteer effort.  Furthermore, statements
and terminology such as yours is more likely than not grounds for getting your
bugzilla privelages revoked.  I suggest you take a deep breath, go outside, then
come back and apologize for spamming all of us with your insulting remarks.
ben, get a grip, please point out where ive insulted or threatened anyone.
you may not like my tone, but then frankly, i do not like your
condescending attitude either...

im well aware this is a volunteer effort, you may have noticed how
i just volunteered to work on this bug, should brian's have wasted the 
the last 2 years.

i want this bug closed, all i can see is brian blocking that target by
saying hes "volunteered" 2 years towards it, but has nothing to show for
it. All he has to do is provide some sort of progress report to show
what hes done, and i'll shut up and let him get on with it, but if hes done
nothing, as it appears, i plan on getting this into mozilla in a fraction
of 2 years. 2 years!! jesus.

im not going to apologise for trying to motivate brian to either finish
the job, or comment on his progress. I want this bug closed, and 2 years
is far too long. i dont know how your getting "spammer" from my comments,
and "insulting" is entirely different to "offensive". i can assure you im not
trying to insult you or anyone else, but im not really that interested
if you find me offensive.
I agree with some of what Jason has said.

Ben: Stop whining like a little girl because somebody has said "dick" in a 
comment. I would like to see this feature in moz, and IMHO, there are only two 
ways that is going to happen:

1. Somebody motivates Brian "NeTDeMoN" Bober into completing the work assigned 
to him.
2. Somebody else completes the work. I admit I do not posess the time nor the 
skills to volunteer, but evidently Jason has.

I challenge you to find another Project, commercial, voluntary or otherwise, 
where what appears to be a trivial task if not completed within 2 years of 
being assigned, is not reviewed. 

I've been waiting a long time for this, and Brian's Laissez Faire attitude is 
no longer cutting the mustard. I say let Jason try and get some response out of 
Brian.

I understand why you are trying to defend Brian, users feel under obligation to 
show respect to the developer who is implementing the features they need. But 
realise this, Brian is not the only person with the skills and interest in 
getting this feature complete and I believe another developer will better serve 
us, as users. I fuly support Jason in his efforts to aquire a response from 
Brian, if it means we will get one step closer to getting this bug closed. I 
know its one of the final steps towards getting me to migrate completely to 
mozilla.
im a noob to mozilla and i was about to start a bug like this one until         
i saw this one. this is the thing that i will miss most about internet          
exploder it is nice to just click and move around the page with this            
auto-scrolling.                                                                 
                                                                                
sorry for jumping in the middle of a argument but if people have been           
waiting for this for years and someone is offering to get it done               
quickly why arent they ?                                                        
                                                                                
btw MOZILLA ROX. that is all.                                                   
Good grief.  Assigned-to is just a placeholder, and does not necessarily mean
someone is currently working on a bug -- never has.  People say "Taking this bug
because I have a patch" every day in bugzilla.  If someone else has a patch that
works, attach it to the bug and take ownership.  Whining and insulting people
has never been a good motivator; patches speak louder than words.
god. your all scared to death of offending each other or expressing an opinion. 
its pathetic.                                                                   
                                                                                
let me ask you all a question, youve all added yourself to the cc list, or      
voted for this bug, some of you have been here since the begginning. Do you     
want to see this bug closed or not?                                             
                                                                                
here are the facts.                                                             
                                                                                
1. im willing to work on this bug, as are other volunteers.                     
2. i have time to invest in this, but not time to waste. im not prepared        
   to start working on this until im confident nobody else is, and that         
   my work is going to be useful.                                               
3. nobody is disputing that ASSIGNED is a place-holder, but its there for       
   a reason ****. Its effectively a semaphore lock, you dont have to         
   obey it, you can still open the file for reading/writing/whatever but        
   its not a great idea.                                                        
4. newsflash: just because you dont like being insulted or offended, it doesnt  
   mean its a poor motivator. i see it everyday, trust me on this. its not 
   personal, get over it.     

you can do whatever you like, suck upto bober and maybe he'll make you his lap  
dog, or be bland and inoffensive enough and maybe you'll get invited to the     
bugs 3 year anniversary party. heh.                                             
                                                                                
so LISTEN UP.                                                                   
                                                                                
i WILL get this bug moving.                                                     
i WILL get a response of bober.                                                 
i WILL get this feature into moz.                                               
i DONT CARE if you dont like me.                                                
i DONT CARE if you agree with my methods, aims, whatever.                      
i DONT CARE if your not going to send me a christmas card.
Re: Comment #54 From Jason Algol  2002-11-06 14:23

> its pathetic.

You've spent the past few comments on complaining about the Assignee. Isn't
*that* pathetic? You've caused lots of bugspam.
                                                                                
> 1. im willing to work on this bug, as are other volunteers.                    

NOBODY is keeping you from doing so.

> 2. i have time to invest in this, but not time to waste. im not prepared        
>   to start working on this until im confident nobody else is, and that         
>   my work is going to be useful.                                  

In that case, let it be and wait - as all others do and can do - until someone
else does the work.

> i WILL get this bug moving.                             

Not the way you're doing it right now, no.
                        
> i WILL get a response of bober.                                 

How about just e-mailing him. And don't tell me you haven't thought of that yet.
Jason: 
SHUT THE HELL UP
You are the biggest dick I have EVER run across in ALL of bugzilla.  Despite
what you may think, your scorning of proper etiquette and a professional
attitude will get you nowhere but on everyone's shit list.  


I highly suspect that you are just a goon from the forums.  I've never seen your
name or email in my 4 years of involvement with bugzilla.  So allow me to
condescend to you one last time:

Shut up, submit your retarded patch if you like, and lastly but most
importantly, go away.
Cruncher: of course ive emailed him facefuck, i may not be proffessional, but   
im not a fool.                                                                  
                                                                                
and yes i will get this bug moving, i dont care if you dont like my methods     
or my bugspam, you can kiss my ass. im not going to "let it be and wait" i      
want this work done yesterday, the assignee has had 2 years to get the          
work done at his leisure, now its time for action or re-assignment.             
                                                                                
Ben: Bite me. im not going to SHUT THE HELL UP because you dont like what       
ive got to say, im just going to say it louder and louder until im drowning     
out your whining little voice.                                                  
                                                                                
do you think im interested if im on your shitlist? who exactly are you ?        
                                                                                
im not going anywhere until this bug is closed, i dont care if bober writes it, 
i write it, or anyone else.

Just for the hell of it, I'm going to add my $.02.

I don't care who makes this work, as long as it gets done soon.  While I may not
agree with Jason's methods (and we have yet to see any work), at least he seems
motivated to do SOMETHING about this feature.

I would feel motivated to help, but I am only learning C++ at the moment, and I
don't think I'd be much help.

So, let's drop the namecalling, and get down to work.

Jason: If you feel that you can successfully make this happen, then do it, and
don't worry about Brian.  Otherwise, let's wait and see if he's making any
progress at all before going any further in this discussion.

And I do realize that Brian has many things going on besides working on this, so
I feel it is fair to at least let him respond.

'Till then...
im going to start doing some work on this when i get back from work tonight, im
already tired of waiting for bober.
Everybody calm down and read what Akkana said. Twice.

There has never been anything stopping anyone from writing the code, attaching
the patch, taking ownership of the bug, and driving their changes into the tree.
Blocks: 164421
http://mozscroll.mozdev.org/ ... it appears that no one has been paying any 
attention.

"this guy has been working on it for _2 years_" ... Actually... no. I worked 
on a it a lot for a few months a couple years back and then only occasionally 
from then on. What happened was that I wasn't experience enough with the code 
and with CVS and tree management and things were going to slowly. That's why I 
stopped working on that and went on to smaller bugs. Just because you know C++ 
doesn't mean you can work on this project without learning about 10 times what 
it took to learn C++. I have known C++ since I was 14. I am now 22.

If you want to help me then when I'm ready I will add developers into 
mozscroll.mozdev.org - that is when I am putting in support for other 
operating systems besides windows and ironing out all the kinks. Until then, 
more developers will just slow me down.

If you have a patch, then lets see it, otherwise be quiet. As of yet, there is 
no other interest in implementing this and if you have never written a patch 
before, this is probably a bit out of your league as it was mine two years ago.

I recommend you guys pay attention before making fools of yourselves by 
stating things that contradict comments in this bug and related ones.

>------- Additional Comment #162 From Brian "NeTDeMoN" Bober 2002-10-14 22:18 -
>------ 
>I have done a lot of updating of http://mozscroll.mozdev.org/ but I haven't 
>activated it yet.
>
>------- Additional Comment #163 From Brian "NeTDeMoN" Bober 2002-10-14 22:44 -
>------ 
>I added bug 174495 about Dave Booth's issue.
>
>Also, see bug 133054 which will also be dealt with in 
>http://mozscroll.mozdev.org/


Obviously I have been doing work on this bug. Where have you been? Have you 
even bothered to read the bugs that are related to this one? I am a bit slow 
in responding to emails... But I do not respond to threats or abusive 
statements, and until you have done more work than I have for this bug, it 
stays assigned to me. Period. Thank you very much and have a nice day.
I do understand if you want this implemented... But I do not agree with the 
level of aggressive attacking going on this bug. Please take a big, deep 
breath, relax and take a look at http://mozscroll.mozdev.org/ ... Most of my 
news and updates will be on that site. 

I believe this very large Mozilla change (patch) needs to be done almost 
perfect the first time. This is not a bug I feel can be done piecemeal.

When I feel it has gotten far enough to be usable, I will provide .xpi's that 
will give you the ability to add the functionality to Mozilla before its in 
the tree. It might be quite a while from that point when I consider it 
reasonably usable until it is actually moved into the tree. Take a look at how 
long it took before Multizilla tabbing was added to the actual tree.


Also, this bug is only about the way to activate bug 22775. The excerpt in 
comment #61 was from that bug. Here is a link that will take you directly 
there: http://bugzilla.mozilla.org/show_bug.cgi?id=22775#c162
This is efecting a lot of people look here http://forum.deviantart.com/803888

Please stay on topic. This bug is about how to activate autoscroll/panning in
various operating systems only.
Whatever you do, unmodified middle-click must still queue links in new 
tabs.  On all platforms (well, at least Win32 and X11).  And by "links" 
I mean not just anchor tag horizontal references, but also anything with
an onclick handler, submit buttons (pending bug 17754), and so forth.
XFree86's nasty middle-click paste behavior will be usable by a preference, in
which case this behavior will be moved to some other modifier.

Any issues on the existing XUL implementation (I didn't write) should be
mentioned in http://autoscroll.mozdev.org/
Product: Core → Mozilla Application Suite
An autoscroll implementation landed (bug 304563), activated like Firefox's (and
MSIE's) implementation.  I'm not sure if that makes this bug fixed or
irrelevant, but marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: