I think it would be great feature if middle button mouse scrolling was
implemented in mozilla. Similar to IE. Where clicking the middle button
would let you scroll around the web window.
not a real UI design bug. eli, do you have any idea that who will be interested
in looking into this?
Handing over to Don to add to his Browser Wish List pile...
OK, do as elig said, add to don's wish list...
bug 25295 is very similar to this...
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Move to M16 for now ...
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs
to Matthew Thomas (email@example.com).
Matthew Thomas is now the QA owner for the User Interface: Design Feedback
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser
should continue be QA assigned to firstname.lastname@example.org.)
Somebody enlighten me -- is this: (a) clicking the middle mouse button turns the
left and right mouse buttons into Down and Up buttons respectively, or (b)
clicking the middle mouse button turns the cursor into a hand for dragging the
page around (as in Acrobat Viewer)?
kind of like acrobat. IE shows this behaiviour very well, if you have your
mouse set up correctly. you middle click then moving your mouse up or down
will scroll the page in that same direction. It's not like acrobat though. When
you click in ie it leaves a litttle mark. when you move your mouse away from
the mark the page will begin to scroll. You do not need to keep moving the
mouse to keep scrooling. As you move your mouse further from the point the page
assiging to myself to look at
why is this marked fixed?
we're doing some triaging and I marked it fixed so i'd be sure to see it and
revaluate it's status shortly.
If you would like to do so*, that would be greatly appreciated.
*that means clearly stating the expected vs. actual results when reproducing
this bug on a very current build.
it's not a bug it's a feature request. That means there is no current result,
there is no expected result. The feature request is clearly spelled out in the
whoa, oops. sorry about that. Looks like we read too fast and misintrepeted. resetting milestone for Don (and reopening)
Same as bug 31412?
*** Bug 31412 has been marked as a duplicate of this bug. ***
This is a feature of the mouse driver, not of IE. Actually, the middle button
in 3-button Logitech mice is by default configured to a function called
"AutoScroll" which works exactly as described by the original bug reporter.
However, Logitech's AutoScroll works perfectly in my M18, so I suspect the
reporter is using another mouse driver which is apparently not compatible with
Mozilla for some reason.
Reporter: could you please provide some information about your mouse
(manufacturer, model, driver, settings, etc.)?
I'll provide my specs, because mine doesn't pan with M18 either.
Microsoft Intellimouse Explorer, the latest drivers on their website, and I have
the following configured:
left button as left button, right button as right button (obviously)
Large Thumb Button: Double-Click
Small Thumb Button: Recall Window (Alt+Tab)
Wheel Button: AutoScroll
and, of course, pressing the wheel button, in Navigator 4 and IE (which this bug
is about) causes the document to "pan".
OK, adjusting summary to point out that this is a specific incompatibility with
Intellimouse. Also changing Platform/OS since this is apparently a
Also marking '4xp' since AutoScroll is reported to work in Nav4.x.
Well, autoscroll works fine for me provided you don't get bitten by a focus bug.
Over to Bill for future evaluation ...
Well I'm not sure if everyone is on the same page, so I'll set a few
definitions, based on the IntelliMouse Driver help files:
AutoScroll: An IntelliPoint software feature that enables you to scroll through
a document automatically, without the need to roll the wheel or click the scroll
bar. For example, to AutoScroll through a spreadsheet, click the wheel button,
and then move the pointer in the direction you want to go. As soon as you click
the wheel button, an origin mark appears. The farther you move the pointer from
the origin mark, the faster you AutoScroll in that direction.
Panning: Panning enables you to scroll through a document by simply pressing and
holding the wheel button while you move the device. It is identical to
AutoScrolling, except you must press and hold the wheel button.
So I don't know why, based on that definition, AutoScrolling works for you,
unless you're thinking of another term, or something's wrong on my end. Since
the reporter vaguely describes my problem, I'll assume the former. Scrolling
with the mouse wheel does indeed work, but not AutoScrolling or Panning. Both
work in 4.x, so I agree with the 4xp. Also, I don't know if any other mice
support this behavior, but it may be possible. If anyone has a non-intellimouse
that supports AutoScrolling and/or panning, do tell.
Logitech mice have AutoScroll, too, and that works for me in M18.
Read my 2000-10-18 03:33 comments.
See also bug 38284, which is about Intellimouse's Panning feature.
Possibly a duplicate of this?
Similar, but not the same. This is about autoscrolling (click once and scroll),
bug 38284 is about panning, clicking, and holding, to scroll.
*** Bug 38284 has been marked as a duplicate of this bug. ***
*** Bug 60809 has been marked as a duplicate of this bug. ***
I am going to implement this as my first implementation. Blake tells me it will
be easy, and I need something easy. Reporter: mouse panning is what IE does.
I am going to make it speed up when you move the mouse further away.
BTW - I'll make it not matter if you hold it down. You have to release first
and then click again to turn it off.
Comments From Mike Palczewski 2000-04-28 07:21 describe this RFE
Comments From Dan Nunn confuse this RFE. Technically Autoscroll and panning are
not equivlanent, but the back end implementation is. And the event handling is
nearly identical so they are really the same. Personally I don't care for the
panning as described by Dan Nunn it's nowhere near as usefull as AutoScroll,
however. I'll leave mpt to consider these silly distinctions.
Basically, click middle button and you get a fixed NSEW artifact [it floats
over all content]. Positioning the mouse cursor relative to it affects
direction and speed of scrolling (if mouse is East page scrolls east, if mouse
is SE page scrolls SE). Pressing <esc>, clicking a button, or spinning the
wheel leave this state and clears the artifact. The farther the cursor is from
the artifact, the faster the page scrolls. If the cursor is 2u S of the
artifact and 1u W of it, the page scrolls west at a speed as a fn(1u) and S at
a speed fn(2u).
MSOffice2k and its competitors do something slightly different:
They convert the scrollbars into special widgets and trap a cursor w/in them
(actually I don't think I ever see EW panning in office). Clicking returns the
mouse cursor to its original position and stops the panning. iirc speed is
logarithmic relative to the distance from the center of the scrollbar. The
origin is the center of the scrollbar. Anything N of the origin's footprint
triggers panning N and similarly for S.
FWIW, please support this w/o requiring a wheelmouse. Any 3 button mouse
should be able to trigger whichever implementation we use. And for single
button macs a meta key+click should be able to trigger this mode. Oh, and
since I like keyboards, it'd be neat if I could trigger this by pressing the
scroll lock key [or similar] and then use my arrow keys to move the cursor.
Brian: I know we all appreciate your work, but would you consider eventually
having it matter if you hold down the middle key? After all, that is how the
current NS4.x behavior works, and having to click twice, once to start and
another time to stop using the panning, is less "zippy" than clicking, holding
to pan, and releasing. The current behavior in NS4.x works both ways.
I could make you not have to reclick if you hold it for a certain amount of
time. That would allow what you want to work.
over to lorca, who deals with events such as mousewheel stuff; also cc'ing janc.
Since I don't have access, I will attach the patch here when finished, but give
me a little time, I am new to this.
--> XP Apps.
I suggest Ctrl+click (Command+click on Mac OS), on anywhere other than a link, to
invoke this on mice which don't have a middle mouse button.
reassigning to email@example.com since he offered to take it.
I accept - I will set it to mozilla 0.9 for now. I will start working on this soon.
Perhaps this feature could be implemented with calls to the windows API? The
Intellimouse drives enable autoscroll/autopanning in every windows application
-- IE, NS4.x, Notepad, Winzip, etc. all have no problems with it (but strangely
Mozilla does); it also works in the common dialog boxes (save/open etc.). It
seems that Mozilla has no problems with this feature working in the Open File
dialog box, which apparently is a windows common dialog.
BTW, this isn't an Intellimouse-specific thing--everything that has been said
about the Intellimouse also applies to my Logitech MouseMan+.
Absolutely not. This RFE is for XP. That means we reinvent the wheel [well
actually we're reinventing the pan --BUT...].
And fwiw, the word IntelliMouse IS NOT in the bug Summary. Please don't make
trivial comments w/o first learning how mozilla and XP work.
*** Bug 63651 has been marked as a duplicate of this bug. ***
Just my 0.02$
Since this is a feature that should be available on all platforms (and with all
mice), it's not particulary interesting if IntelliMouse is supported in Windows
(all mice in all platforms must be the target, like firstname.lastname@example.org said).
With that said I have a personal opinion.....It should be able to be activated
and stay activated without the need of having any buttons pressed the entire
time (this way i can lean back and just wiggle the mouse without worrying about
Also some thought should be given to using the middle-mouse button (it's
currently "open link in new window" on Linux platforms for instance). Not saying
it's wrong, just that such cases must be considered.
email@example.com please read paragraph two of my specification [2000-12-04
19:05]. However, wiggling will definitely cause the panning to change, which I
hope is acceptable. When the user finds a suitable rate and direction the user
stops fumbling w/ the mouse/keyboard and just reads or scans.
One minor correction, i think i meant exponential not logarithmic. Sorry for
the confusion. In English: the closer you are to the artifact the more precise
[and hence slower] your scrolling is, the farther you are from the artifact the
faster the document pans.
Nothing I said was against or duplicate of what you said in above post, probably
a slight confusion......by "wiggling the mouse" I just meant that all panning
should be able to be done via mouse movement without any mouse/keyboard buttons
pressed once the mode has been activated....not that I should actually be able
to "wiggle" the mouse (english isn't my native language :-).
As for the increase in panning speed in proportion to the distance from the
artifact, I've tried the logitech software on Windows and it's probably
exponential or logarithmic, I'd suggest we use linear though since all distances
> 2 cm from the artifact are too fast to be used (in the logitech version, I do
understand that you might want to jump quickly to the bottom of a doc but moving
7-8 cm from the artifact will accomplish this as well with linear increase).
That's something that can easily be tweaked once the feature is implemented though
*** Bug 63695 has been marked as a duplicate of this bug. ***
[Resummarizing for clarity]
mpt: this bug is for the implementation of the feature. it is NOT for the
specific triggering mechanism please do not squish my summary.
Bug 63712 is now specificly focused on how to trigger this feature. I think
each triggering mechanism should be blocked by both this bug and that bug.
Just my $0.02. I would really like to see this also. A suggestion I have is
that this would work in 8 multiple directions. With the latest IntelliPoint
Software (Sorry to use a MS example), you can scrool/pan the document in 8
directions (where appropriate) rather than just the standard four. To clarify:
if the document it to large vertically and horizontally, you can move north,
south, east, west, northwest, northeast, southeast, and southwest. If the
document is to large just vertically or horizontally, there are just two
directions. This comes in very handy when working with large documents.
Thanks! Look forward to seeing & using this new feature!
This is a summary of the last year of messages to organize them - except
triggering (Bug 63712):
It has been noted that some expensive windows mouses, such as the Optical
Intellimouse Explorer already implement this feature. In my experience,
Intellimouse doesn't work in NS6, but Antti says that the Logitech
implementation works in M18. Obviously we want this to be an
OS independant feature and the Windows implementations already existing might
interfere. At first (in my opinion) we should get this working on every OS with
the same code (and test on Windows systems without the special mouses). Later,
we might have to take further action to make the special mouses compatible. One
such action might be Windows code that hooks the mouse messages from the driver
when the mouse is over Netscape 6 and doesn't allow them to reach the programs
that give the built-in autoscroll feature - if that is possible.
There have basically been two modes talked about here:
When triggered (probably by a middle mouse click), a N/S/E/W artifact will
appear and one will be able to scroll the page in either 2, or all directions.
A page with just one scroll bar will allow only 2 directions. A page with
vertical and horizontal scroll will allow many directions and 8 cursors for
different directions directions (N,S,E,W,NE,NW,SE,SW). When one moves the mouse
farther away from the point where it was triggered, the page scrolls faster.
Then another action disables it. The cursor would show the direction moving and
there would remain a NSEW icon where the triggering action occurred. The speed
should be a function of the distance in each direction from the central cursor -
as timeless noted. That way it would seem it only scrolls in 8 directions, but
it would really scroll in all directions. The velocity vector is a two
dimensional vector that depends on distance x and y from the centerpoint.
Therefore, if you integrate the velocity - you see the position vectors allow
for more than 3 discrete directions for each axis.
Most likely this will be quicker to use for simple scrolling - when triggered
(probably click-dragging with the middle mouse button for longer than the
average click). Moving the mouse further away will have the same affect except
that in this mode the window can only move up or down. This would be another
way of doing something similiar to what timeless noted with Office 2000. In
2000, the cursor moves into the scrollbar and you can scroll it by moving the
mouse, then it returns to the original position. I do not believe that the
cursor should be stuck into the scrollbar in Mozilla because that is a waste of
time. Instead, a N/S artifact will appear. Moving the mouse up or down changes
the velocity. Again, the cursor will show the direction scrolling. I have to
give David credit for a great idea. If people remember the old MS-DOS text
editors, wiggling the mouse would cause faster scrolling because interrupts
occur faster. Wiggling will cause the function to be multiplied by a scalar to
make it scroll faster. Without this major distinction between panning mode and
autoscroll mode, I would have to ask - why have it?
Note: Bug 63712 is for discussing how to trigger the event. Something has to be
done for mackies where a multibutton mouses are more the exception than the
rule. Suggestions have been made for a CTRL + Click / Command + Click combo.
This would probably be a good choice but should be talked about in that bug.
Notice that most PC mouses that have no middle mouse buttons can simulate it
with a two button click.
In reply to Andrew's comments, I do not believe that using windows APIs to do
this would be a good idea. This bug is not for implementing just on the windows
system. The only reason to
use windows APIs should be to block the interfering mouse drivers - if possible.
Hi, this is in response to boberb's nice summary and update:
In your summary you make a distinction between an autoscroll and a panning mode,
and I think that I can offer some insight into the situation. When you talk
about panning mode, you describe how it works in office 2000 and then mention
the other, better way to do it (ie, not having the cursor appear in the
scrollbar, but have the artifact show up anyway). The behavior you suggest is
the exact same behavior as normal microsoft intellimouse mice work in win32
(they're not all that expensive:) ).
With intellimouse drivers, the artifact/scrolling behavior is exactly the same
in what you call both panning and autoscrolling, the only difference is how they
are activated. There are two ways for things to work:
A) you click once, causing the artifact to appear until you click again.
B) you click and hold, and the artifact appears only until you release the button.
I believe that B) is essentially what you were talking about when you wrote
about panning mode, and please correct me if I am wrong. I personally enjoy "B"
operation as it is quicker and requires less click-work. It is also the
intellimouse standard to have both modes (anyone know if logitech does this too?).
As a side note, the intellimouse autoscrolling functionality worked fine in
mozilla until the xp widgets were activated. I used to be able to turn them
off, get normal win32 looking scrollbars, and intellimouse would work. It's a
shame mozilla has to work around this now, but cross platform homogenity is cool.
Yes, your interpretation of what I meant by panning mode is correct - and the
way you said it will be triggered is probably how it will be implemented,
except remember that Bug 63712 is for talking about the specifics how it is
I believe that it will give Netsape/Mozilla more control to do the
autoscroll/panning itself. Of course, the main reason is homogeny between all
OSs. Other reasons are the fact that Mozilla would be limited to whatever the
makers of the drivers decided and would have to access each OSs APIs when it
might be easier to just tell the OS not to process the messages. Besides... It
has to be implemented better than Microsoft does it to make them look bad.
Intellimouse SDK :
I will assume logitech uses the Microsoft standards for the Windows operating
The WM_MBUTTONDOWN message tells when the middle button is clicked. The
WM_MBUTTONUP tells if the button is released. If the program processes this
message, it returns 0. Hopefully, all that Mozilla has to do is return zero to
this message and it will block the default panning/autoscroll program from
In Microsoft's autoscroll, there are three zones:
Neutral zone = 16x16 zone where scrolling doesn't occur
Delayed scrolling zone = scroll very slowly.
Accelerating scrolling zone = Outside the delayed zone - scroll exponentially.
I believe that there only needs to be two zones: The Neutral zone and the
accelerated scrolling zone. I have noticed that scrolling speed changes very
rapidly with the Intellimouse. Possibly, exponential is not the best function,
and quadratic would be more appropriate.
Based on Microsoft's document, the slowest speed would probably be about 16
pixel/sec. We probably want to make the distance one would have to move the
mouse to get to 1000 pixel/sec about 200 pixels. The maximum speed would depend
on the page size and would just be because anything larger would not be needed.
If we make the neutral zone 16x16, then if out of the neutral zone:
maximum = max ( page size / seconds, 1000);
distance = distance from center - 16
constant = 200 / sqrt(1000) ~= 6
speed = (distance/constant)^2
if the delay per scroll is 50 milliseconds:
if speed > maximum then speed = maximum
if speed < minimum then speed = minimum (minimum probably being 16)
pixels per delay = speed / 20
distance speed (in pixels / sec)
*** Bug 64009 has been marked as a duplicate of this bug. ***
*** Bug 65004 has been marked as a duplicate of this bug. ***
OK... I am going to start working on this tomorrow.
A change to panning mode:
The cursor will change to a NS cursor, and moving the mouse up or down will
scroll the page. If you move the mouse to the top of a region around where you
started, the page will be moved to the top. Move it to the bottom of the
region, it will scroll to the bottom. If you move it to the far right of the
region, it will scroll the page all the way to the right, and the same with the
left. The position on the page will be how far between the top and bottom of
the region you are. Also, there will be a small region that does nothing, just
like in autoscroll. Therefore, this will act as an expansion of the scrollbars.
Let me get this straight: with the change to the panning mode, do you mean that
if I hold the mouse still, the page (or any other content, this applies to
dropdowns and other scrollable controls too, right?) doesn't scroll? I.e. the
mouse movement controls _distance_ of the scroll, not the _speed_ of it like
mentioned earlier with AutoScroll?
This is a feature I really long for. The ThinkPad TrackPoint driver has
functionality like this and I cannot live without it any more. Unfortunately,
it doesn't work with Mozilla (for the well known reasons). I really don't
get good enough control with the AutoScroll type of scrolling, although
the speed envelope changes you suggested may help there.
I can even think of a fourth way to scroll, where you would virtually grab the
content rather than the scroll bar like above. I.e. when moving mouse by x
pixels, the content would scroll x pixels instead of the scroll bar moving x
pixels. When you need finer control of the scroll, this mode might be
risto: If you want to do a grabber tool like in Adobe Acrobat (I am assuming
that is what you mean), I suggest you make a new bug on that (If one hasn't
been filed yet). That sounds like a good idea. Your interpretations of what I
meant by panning are correct (If I am interpreting you correctly). It is stupid
how Microsoft makes panning and autoscroll equivalent.
Okay Okay, hold the phone... lemme get this straight: I click and hold with my
middle button, an artifact appears. I move my mouse up and the page scrolls up,
but then if I stop moving my mouse up, (that is, hold the cursor somewhere above
the artifact) the page will stop scrolling up? That's not very useful, it only
allows as much scrolling as screen space allows, and you need to keep moving.
I'd just roll my mouse wheel if I wanted to scroll a little.
The implementation I thought had been agreed upon a long time ago was that the
page would keep scrolling, and the further away from the artifact, the faster
the scrolling. This is the current implementation of Intellimouse software and
I'm pretty sure Logitech works like that too.
Yes, that is Autoscroll mode. There are two modes, autoscroll and panning. Look
up to see what I originally wrote about panning and replace it with what I just
wrote. If you think I am wrong then tell me. Autoscroll will remain autoscroll.
In short, Autoscroll: If you click the middle mouse button, move the mouse
cursor up, and the page scrolls. If you do nothing, the page continues to
scroll. We have to differentiate from panning though. Panning is what happens
if you hold the middle mouse button, and the page acts as if you are holding
the scrollbar tab. You can drag the page up and down to the right position.
Having the same function for panning and autoscroll as Microsoft does it would
just be pointless. If you think I am wrong then tell me. I haven't implemented
BTW: Panning and Autoscroll will have different triggers on other systems (Bug
63712) I am talking about on Windows. For instance, most Mackies have no middle
mouse button (They have one button). Most Unix users use their middle mouse
button for other stuff. (Cut and paste?).
Again, I personally hate how dragging the middle mouse button (panning) does
the same thing as Autoscroll on Windows. If I am somehow flawed in this then
tell me. I am definately still open for opinions.
Thank you for clearing that up. Sorry if I seemed over-zealous. In win32, I
personally prefer getting the autoscroll (as defined above) behavior by
clicking, holding, and letting go (the mouse actions used for panning). This is
because it's quicker and requires less clicking than the click-release-click of
the other option (this makes it more like a nudging than a full blown operation).
Now that you've explained it again I see your point and agree that your behavior
has significant value. I offer that we consider reversing the modes, though
(ie: click and hold gives autoscroll, click release gives panning). This is
because this matches more closely to microsoft office behavior (office being the
only other place I've personally seen similar behavior). The office behavior,
of course, isn't quite the same as what you describe, and far less functional
IMO. What do you other people on this list think?
Ben: Thanks for the input. You might be correct that the triggers should be
reversed. I believe bug 63712 should be the place to talk about the trigger as
timeless set it up for that. Initially, the trigger can be a call to a
autoscroll is Microsoft Intellimouse's way of doing it, and panning is the way
that it has been done in other contexts in the way I describe. On further
inspection, Word is identical to Intellimouse except for the graphics and the
fact that Word embeds the graphics in the scrollbar and doesn't have EW
function. Therefore, Word's implementation stinks IMHO. ;-)
Brian: Yes, grabber was what I was refering to, too. Personally I care most for
this newly defined panning mode. I just thought to mention grabber here as we
were going through different ways to scroll. But maybe you're right that it
isn't in the scope for this bug. I think I'll report it separately...
Ben: I think you are able to scroll the whole document in panning, if I
understand it right. What it basically means is that moving the mouse x pixels
up scrolls as much as moving up the corresponding scroll bar by x pixels. So it
virtually grabs the scroll bar, you don't have to explicitly move your mouse
over it. This is especially handy, if your window is partially off-screen. With
a long document the panning can be a bit too fast, that is why I mentioned the
grabber alternative that could be supported in addition. Here the document
scrolls only as much as you move the mouse. Maybe you thought this grabber thing
About the trigger, I think autoscroll more clearly puts the program into a
special mode that you enter and exit. In panning you are actively scrolling,
like you keep the button down when you scroll using the scroll bar thumb. That's
why I think autoscroll could be activated by click and panning by grab. The best
thing would be of course to have this be freely configured like the scroll wheel
functionality. But Brian is right, this is stuff to decide in bug 63712.
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
I found out that grabber scrolling RFE is in bug 60978.
I took a break from working on this bug to alter query.cgi and make a
queryhelp.cgi for bugzilla 2.12, but now that that's fully finished (I think) I
am going to continue working on this. Currently, the display of autoscroll
looks correct, and all I have to work on is the actual implementation of the
Just a note to point out that if the Logitech implementation (which they call
"universal scrolling" just to confuse the terms even more) was working in M18
for Antti, its sure not working for me with current nightlies - I didnt own a
logitech pointing device when M18 was current but this feature has never worked
for me (on WinME/Logitech trackball/latest drivers) with any nightly from the
last couple of months. FWIW, mozilla is the only app with a scrollable window
I've been able to find that doesnt respond as expected but it sure "tries" to
respond - its getting scrolling events from the OS but it doesnt scroll the
correct component as I reported in 70876
doesn't look like anyone has commnented on this bug for awhile.
time for RFE work in 0.9 is up. moving to 0.9.1. let me know
if this causes problems. thanks
*** Bug 70876 has been marked as a duplicate of this bug. ***
*** Bug 79403 has been marked as a duplicate of this bug. ***
does anybody have code or a plan for getting this work completed?
if so lets set the milestone base on the best engineering estimate.
unsetting the target milestone.
I am planning to work on this. I need to know more info on how to hook
Status update: I am learning XPCOM and starting work on this.
Brian: Have you considered trying to somehow trick windows into thinking there
is a native scrollable window where the mozilla window is? This was done with
the url bar, where an invisible native text box that cloned the url bar was
created so that programs that looked for it in other browsers would work with
If you could create an invisible native window that constantly overlayed the
mozilla browser window, then possibly you could get everyone's microsoft,
logitech, etc... mouse driver to recognize that and the mozilla window would
behave like a normal windows window with their particular driver and settings,
which I think is really what everyone wants.
Just an idea.
Ben, like Brian says on 2000-12-28 22:42, this should be an OS, mouse and
mouse-driver independent feature.
I realize that it would be nice to have mozilla completely OS independent, but
the fact is that using non-native widgets just plain sucks. Nobody wants an app
that works completely different from the rest of thier apps/OS. People will be
A) The autoscroll isn't what they're used to with thier native mouse drivers
B) When they get a new mouse with some new fangled features, they won't work
C) People buy their mice in part because they like the features that come with
the drivers. Mozilla will use what mozilla wants to use, and people (including
me) will think that will suck.
I know that brian will make a good autoscroll thingy, but that still doesn't
negate the above items.
So this doesn't get out of control, I'll comment on the status of the project
so far, which will explain a few things.
Originally, I started making the code in the chrome, which didn't give me as
much control as I needed, so I started making it in XPCOM. So far, I have
decided how the autoscroll/panning system is going to work and done a little
XPCOM coding. Unfortunately, it is very hard because there isn't enough
documentation about the hierarchy of the Mozilla c++ code, such as the event
system. So it has been a learn-as-you-go sort of thing.
the code in widget/src/your-os-here, can place two events in the NS Message
That is intercepted by XP code in nsEventStateManager.
That way, no matter what OS you are on, those event messages will tell the XP
message handling code that the event has occurred. The os-specific code in
widget/src will determine the trigger (bug 63712) so every os can have its own
Also, the graphics of autoscroll/panning will, in Windows, will be identical to
that used by Internet Explorer. I believe that making autoscroll/panning depend
on a set of mouse drivers would be very bad as we would be making our code
depend on others' code.
Implementations of autoscrolling/panning are done by the program, not the
drivers. With a regular 3 button mouse, you can still autoscroll. My laptop's
built-in middle button can do autoscrolling.
I don't think it will kill someone to edit Mozilla's preferences for
autoscrolling instead of doing it in their mouse settings in the control panel.
It is better to go the OS-independent route in order to make a program that
people can count on working the same no matter which OS they are on.
Besides, MSWord implements autoscrolling differently (try it).
You provide a good argument, though. Maybe there should be a setting in prefs
that lets you choose between windows-style panning (identical to autoscroll
except a release of the trigger ends the session), or Mozilla-style panning.
Autoscroll will be very similiar in Mozilla to that of Windows.
11 dups. Marking mostfreq.
*** Bug 85176 has been marked as a duplicate of this bug. ***
It is coming along great. Autoscroll is done and panning is soon to follow. I
am currently adding the ui for the events. After that, I have to add the
panning support, and support for outlineboxes and trees. Then I have to get rid
of the abundant memory leaks, document the code and I'll be done. I'd say I'm
about 1/2 of the way done.
By the way, you guys (especially Linux and Mac users) need to start coming up
with ideas for bug 63712 - choosing the way to trigger autoscroll.
Hey Brian, are you still going to allow both of the following methods to trigger
autoscroll for win32?
A) click and release middle button / wheel places artifact, and the artifact
stays there until there is another click
B) click and hold middle button / wheel places artifact, artifact disappears
upon release of middle button
I'm a big fan of (B), both (A) and (B) can coexist without changing prefs, and
this is how intellimouse works. Don't mean to be whiney, but I know there was
some arguement about this earlier...
Middle mouse button = default trigger for windows.
Please call it the trigger from now on and not the middle mouse button (for xp
The trigger will be changeable in prefs.
Ugh, by panning do you mean the equivalent of Adobe Acrobat, where the little
hand appears and you drag the page around? If so, I'd like to request a pref.
that both A and B produce autoscroll, which is how intellimouse works. Panning
is pretty much a slow and less usefull alternative to autoscroll (IMHO), and I'd
rather be able to autoscroll by clicking, then releasing, than to have panning
as an option.
BTW, k-meleon (mozilla-based browser) already has this functionality.....maybe
it could be integrated directly into the code.
re k-meleon: No, No and No.
For the first reason please see Comments From firstname.lastname@example.org 2000-12-22 08:10.
Another interesting reason k-meleon is absolutely useless to us is that its
license is incompatible so even assuming they didn't just let a native class
handle it we can't use their code.
Since netdemon is already well on his way such comments should not be added to
this bug. please let him this bug to indicate progress and attach patches. *and
now back to our reguarly scheduled bug*
Timeless: I think they should especially read a series of other statements too.
Therefore, they should read the whole bug. I am not going to reply to anything
if I have already answered the question. Ben, I have already answered your
question. If you read my last 10 or so posts and are still confused then I will
Ben: sure the pref can be added. We will probably file a new bug for prefs when
all the regular autoscroll/panning code is done. I will put the backend for that
Timeless: thanks for your help.
Basically guys, I am sick of repeating myself. I often have to reread my
statements to remember what I have said, so it won't hurt you to read them also.
Hey Brian, sorry about that. I was more or less posting to nag/whine/make sure
nobody changed their mind, and to try to catch things while the feature was
being made, rather than later. I'll shut up now till the feature is done :)
Hey, no problem, but please use email next time. I found a bug that could
degrade the performance of autoscroll/panning if that bug is not implemented
correctly. Bug 33966.
If implemented correctly though, it should make it work better.
*** Bug 88624 has been marked as a duplicate of this bug. ***
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.
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
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.
*** Bug 93360 has been marked as a duplicate of this bug. ***
You can achieve a crude version of this behaviour through the use of
Go to http://www.bookmarklets.com/tools/look/index.phtml and do a find for
"Scroll Page". Not ideal but it's a start.
It just occured to me that Mozilla already supports a kind of autoscroll: If you
hold down the left button to select text and move the mouse over the top of the
document page, Mozilla starts scrolling with a speed relative to how far you are
over the top edge.
Anything to borrow or reuse from the implementation of that?
*** Bug 94998 has been marked as a duplicate of this bug. ***
risto: unfortunately... no.
After 23 Months is this feature included or not?
If you are still confused about this feature simply look at IE 5.x+. Click
middle mouse button/wheel. Observer behavior.
If you haven't figured out the importance of the is feature just consider this.
I'm reading a long web page (such as this one). I simply click the middle
button and move the mouse a little bit down and the page scrolls slowly at a
constant steady spead. I have to have no interaction other than that one simple
click and scroll. With out it I have to manipulate the page every screen full
at a time.
jason: if you bothered to read the posts you would see that I'm already halfway
done and haven't been working on this for 23 months. Therefore, please read
before making another comment.
Dear Brian "NeTDeMoN" Bober,
Half way done, is not done at all. Either it works or it does not. As it is now
pushing the middle mouse button does absolutely nothing in this browser. Which
release has this feature?
Since I originated this feature request, yes I do read every addition to this
thread, thank you very much for your comment it really helps a lot.
Whoa whoa whoa, before you go and make some more remarks, please consider the
fact that nobody is paying Brian *sqat* to do this. It is completely voluntary
work. If you're gonna make any remarks, thank him for taking any time
whatsoever to devote his skill to this bug. This is open source, you can't go
demanding stuff stuff from these programmers.
I almost hate to do it, but I will say I agree with Jason's sentiment. I've
been very eagerly awaiting for this feature to get implimented. And while it
hasn't been 23 months since Brian has had this bug assigned to him it has been
nearly 12 months. Which for something that was supposed to be "easy" to
impliment is quite aggravating to wait such a long time for.
Also, Brian if you really do have this feature half way done some real updates
on the progress would be nice, as of now just reading the bug comments and
seeing the behavior(or lack of it) in mozilla noone could really tell if ANY
progress at all has been made on this bug.
Perhaps you should request that someone else be assigned to help you with this
bug, it might help speed things up a bit at the lease. And it certainly
couldn't hurt at this point IMO.
I have to agree that we cannot demand anything, but we can offer stuff. I'm glad
that somebody is doing this since I dont have the coding skills to do it myself.
Is there anything Brian can tell us about how its going, how he plans to
implement it and what, if anything, those of us without the code-wizard gene can
do to help?
Heheh. Blake said it would be easy. I didn't. He was joking too. This is a very
complicated bug and touches A LOT of files. Besides the fact that I'm working on
this bug and a couple others, I am also doing school among other things. I
good so I had to learn XPCOM (which is very very well documented as you know ;-)
and started working with the XPCOM codebase in March or so. What kind of updates
are you looking for? There is no UI for this yet (except cursors) so I can't
show you screenshots except of the messages sent to the debug window. I have
already told you what works and what doesn't so I don't know what else you want.
Development was slow in the beginning because I wasn't good with CVS and had to
back up my files every time and download them from FTP. So I know this sounds
like excuses but the truth of the matter is I am doing this as a volunteer
service and therefore you should appreciate the work I'm putting into the
project. I have been learning about the codebase as I went along and now know it
pretty well (at least the parts I have touched). I recommend that if you want to
make things like this faster you find someone to document the codebase. I
basically had to figure out things on my own except the rare occasion someone
could answer a question I asked on IRC. The Mozilla project lacks in
documentation and it needs this in order to go faster. As long as it is poorly
documented the learning curve will be very steep for anyone who wants to help.
So there are a few ways you can help:
1) Get people to document the source.
2) Figure out how this is going to be implemented on other oses. Please see the
3) Get bug 63712 resolved since until it is resolved this feature will only work
on windows. We need not only the way to activate it on all the oses Mozilla
supports, but we need cursor suites for every os.
I am going to attach a picture of all the cursors for Windows. Please port these
to other os cursor files. For now just make them identical and after this lands
you can file bugs about changing how they look.
Just realize this is my first major bug in XPCOM and I would like it if you
weren't so critical of how long its taking. I have put a lot of work into this
bug and I would like you to put that into consideration before making blatant
I will have a lot of time to work on this during Christmas break and I assume I
will get pretty far on it during that time. Finals are coming up soon so I don't
know how much I will be able to work on it until then.
Jason: If you want to find someone to help me with this then feel free -
although it might just slow me down working with someone else.
Created attachment 58827 [details]
This is a picture of the mouse cursors.
Please port these cursors to the other oses. The NSEW artifact will look like
the first cursor (on the left) but a different color. After this bug is fixed,
you can make it look different on other oses but I won't be able to do that.
For simplicity, lets just keep it standard for now.
Created attachment 58832 [details]
These are the NSEW artifacts
These are the NSEW artifacts in front of a beautiful blue background. Notice
the form and shape of this wonderful form of abstract art.
*** Bug 110857 has been marked as a duplicate of this bug. ***
This is not a 1.0 blocker according to
Work on this bug will continue but it will not be checked in until
Um, can you please clarifiy that last post? Because it sounded to me pretty
much like "This doesn't HAVE to be done by 1.0 so I'm not going to really try
to get this bug resolved by then."
I'm going to try really hard to still be cival but it's becoming pretty hard.
After all these many many months and all you've shown us is some artifacts
that could be made up in Photoshop in 5 minutes. Isn't there anyone else out
there in the mozilla community "official" or otherwise who is interested in
getting this feature in?
Oh, absolutely, yes, I'm interested, especially since I'm used to using it in
Opera 5 and it's really sexy.
In my humblest of humble opinions, I don't think the implementation can be
solved or usefully discussed in this forum, just whether or not to do it. This
is a MOSTFREQ. I wrote one of the 11 dups. I framed it as a deficiency of
Mozilla. I thought it should be there since Mozilla supports changing the
action of the mouse wheel in "Mouse Wheel" in Preferences. I think that
auto-scrolling mitigated by moving the mouse up, down, right, or left after
clicking the scroll button is the default action. Sorry if I got it wrong.
I really think making this 1.0 would add to the Mozilla UI and make it that much
better received. If it hasn't been happenning over such a long time, maybe more
manpower should be thrown at it.
The format of the autoscroll and panning has already been decided. I believe I
won't have a problem slipping it in if its finished before 1.0 even though its
not a 1.0 blocker but I still had to move it back. It would be moved back anyway
if I didn't move it back but it is my job as bugowner to decide whether its a
1.0 blocker and since its not a performance/stability/or API issue then it
shouldn't be marked 1.0.
Brett: I don't have to prove anything to you. If you think you can do it faster
lets see it.
Steve: What in the world do you expect me to show you? This isn't a UI bug.
Let's be realistic. Do you want me to paste all the unfinished code here, Brett?
Spending time giving massive updates with incomplete patches that wouldn't be
checked in would just slow down development. So tell me what you want to see. As
far as I can tell you are just complaining that its taking so long and asking
for someone else to work on it. I consider that rude and obnoxious considering
the time and effort I have put into this. You have no clue how much work I've
put into this and you have the nerve to complain about it!
From now on if someone doesn't have anything but a rant then take it to the
newsgroups and it won't clutter up this bug with useless conversation that
people have to read.
If you feel I'm not going fast enough, find someone else to implement it and
when they are as far along as I am and their implementation follows the way we
have decided to implement autoscroll/panning (about which I have talked to many
people on IRC), and is well documented, and high quality code then I will give
the bug to them. Most likely, by then I will be finished and their time will
have been wasted because you couldn't wait for me to finish.
Steve: sorry I meant to write Brett on the beginning of last comment.
Brian is right, since this is simply an enhancement, and not a blocker of any
kind, it is best to take time and not rush this feature. Because it is highly
possible that this may bring on many other bugs.
I mean, come on, be realistic, this is simply a "make mozilla look pretty"
feature, it doesn't stop you from doing anything - as long as scrolling works ;)
In my opinion, mozilla1.0 will be to show the world the speed and stability
(hopefully), enhancements are simply add-ons.
And wouldn't it be good to say, "oh look, mozilla1.1 is out, and a major new
feature is smooth scrolling".
Waheed, your opinion seems very balanced and correct to me.
I am getting into this at the end, just because I wrote a dup bug, so I'm
feeling that I have less of an investment in this scroll button process and less
entitled to be a "mover and shaker" in this process, with which I'm sure many of
you will agree. I just responded because I now get changes to the bug, and
although I skimmed through all the prior dialogue, I was really touched by the
question of anyone being interested. Really, please feel free to take me off
this one. I'm not writing the code, and I don't have the big picture to be able
to talk about how much we ought to concentrate on this one.
Brian, I really acknowledge your work on this code, and I know you want to avoid
adding bugs to the current code pool. I admit, though, that it is difficult if
not impossible to guage all the effort that you are putting in just because it's
not in the current builds. I guess that's the way it goes, though.
First of all I want to apologizse to Brian, I wrote my last comment in a
frustrated state and don't want him to think I have a vendetta against him or
that I am going to attack him whenever I am displeased etc.
Brian, I don't doubt that you have put a lot of hard work into this feature
and you probably are in the bad position where you can't show everyone the
progress you've made because of the nature of this bug, which also means we
can't really get a feel for the progress you do make.
Secondly, although this is probably considered by most people as a *whiz-bang*
type of feature, but to me it's much more of a major usability feature due to
the fact that I use a graphics tablet as my input device rather than a mouse.
So I don't even have the luxury of using a scroll wheel to scroll pages, all
scrolling must be done by manually clicking and slowly dragging the scrollbar
up and down the page. After many years of being weened on autoscrolling in IE
this quite frankly makes Mozilla an annoyance to use and is the source of much
Steve: Yeah, I know how that feels. As you can see I haven't been in this bug
from the beginning. There is plenty left to do and I am sure that you will be
able to help in some way. Just keep up with what's going on. You might want to
look at bug 63712. Maybe you can provide some input on that.
Brian: I just finished reading through all the comments on this one again.
What a pain in the butt! Thank you again for coding this feature. I think it's
important because it increases the functionality of Mozilla, makes it easier to
get from here to there, to skim through stuff.
I know that you are already committed to certain decisions about scrolling, and
that I can't expect anything different than what you are doing. I'll check out
the trigger bug. As far as functionality goes, what you are coding will be
fine. My intent in making this comment is that I have realized that the
Intellipoint driver runs the scrolling stuff in Windows (doh!). I know Mozilla
is intended to be multi-OS, I'm not sure if it is intended to be OS-independent.
If not, I wish it just supported the OS it is running on, including the
I know this perspective may be different than what has been agreed upon, and
that what has been agreed upon will be implemented, but I thought the
Intellipoint software would be an easy way to go. Please disregard the
aforegoing in terms of the implementation, and just look at it as an unuseable
bit of opinion.
definitely think this would be nice in 1.0, but should be written so that it
will not be enabled when pressing the wheel on a link (so it doesn't conflict
with the lovely option of using the center wheel to open a browser tab).
Brian (or to whom it may concern), would you mind giving a progress/status
update on this bug?
Created attachment 79341 [details]
Vertical-only one-dimensional panning cursor
Attachment "58827: This is a picture of the mouse cursors" neglected to include
this picture, which is the cursor used for vertical scrolling. As was already
mentioned, this site (
) has a complete discussion of the mouse cursors, their behaviors, and some
default images for the mouse cursors.
Ok, thanks. Those images were just to show people the cursors. I have them all
in a n .rc file. I guess I forgot to add that one to the image.
I have been working on smaller bugs in the hope I can get them in before 1.0 or
soon after. Therefore, the status hasn't changed. This bug covers a large amount
of the tree, and in order to work on it, I have to be working solely on this
bug. The reason is that some of the files it touches are very active and
therefore working on this bug requires a lot of tlc to stay up-to-date.
*** Bug 140772 has been marked as a duplicate of this bug. ***
*** Bug 141100 has been marked as a duplicate of this bug. ***
*** Bug 147554 has been marked as a duplicate of this bug. ***
*** Bug 144047 has been marked as a duplicate of this bug. ***
*** Bug 152390 has been marked as a duplicate of this bug. ***
*** Bug 157709 has been marked as a duplicate of this bug. ***
Any status updates? 1.1?
Brian: I'm sure we all appreciate your hard work.
Is there any resolution or plan to fix mozilla so that the middle button in
conjunction with the trackpoint will scroll the page. This is really annoying
for just about all IBM laptop owners and this functionality works in just about
every other windows app. Is there any plan to fix this bug?
*** Bug 159806 has been marked as a duplicate of this bug. ***
*** Bug 160906 has been marked as a duplicate of this bug. ***
Yes, I am planning to reorganize the code and throw it on Mozdev.
*** Bug 161692 has been marked as a duplicate of this bug. ***
Once again, any updates for this bug/enhancement?
*** Bug 167796 has been marked as a duplicate of this bug. ***
Grrrr! :-) When there is an update, I'll give one. I have been very busy
lately working 45 hrs a week and doing a ton of other things. Once I get my
Mozilla site up (when I have time), I will provide up-to-date information.
When I make significant progress, I will provide a notification here.
Been following this for quite a while, and donning asbestos, I have to jump in.
With all due respect, Brian, if you're extremely busy, maybe it's time to pass
this bug on to someone else. I'm sure everyone understands that Mozilla
programmers have lives outside of Moz, and certainly everyone appreciates the
work done. But, it's been nearly three years since this bug was first
reported, and no public progress has been made on it; further, for a lot of
people, this is a reasonably basic UI feature that has a profound effect on
their day-to-day use of a program. I can't speak for anyone else, but for me
personally, I have no intention of using Moz until this is fixed, because it's
such an essential interface feature, and I use it constantly. And "once I'm
not working 45 hours a week, and also once I get my site up, I'll post if I
make progress" doesn't strike me as synonymous with "real soon now."
Again: it's not that the hard work isn't appreciated, and I tried to make this
post with all due respect. But maybe for the sake of the program, if you're
too busy to work on this, it should be passed into someone else's court.
Homer (ahem) - your post assumes that there is someone else that has the time
and knowledge to work on this, which isn't necessarily the case. There's no
point in Brian stepping away from this if there is nobody to take over - if
there is someone that is ready and able to do some work on this, then they
should speak up (and I would then hope that Brian could post up whatever work
he's done, so it can be picked up...)
My 2 cents: Brian, I'm in favor of your continuing with this one, but you're the
default programmer anyways so far. I'd just like to throw out an idea. Could
you assign pieces of this project to other people (did I ask this before?)
precisely describing all the parameters and the piece of code, perhaps using
some precise method of returning whatever data is necessary? In short, I'm just
asking if you can chop this thing up and spread it out to other programmers as
well as yourself, with yourself as project manager as well as lead programmer.
um, Steven, and who are these other programmers you mention?
Christian, I think if you asked for volunteers, you would find no shortage of
programmers willing to help out on this. I, for one, would be more than happy
to oblige, in order to get this feature completed.
well, so start working on this :)
seriously, I think this should not be too difficult - just look at Mozgest -
they need to capture mousemoves as well. so you just need to scroll when the
mouse moves, instead of interpreting it as a gesture.
Have just reread all the comments on this bug and I'm wondering about one thing
- Maybe Brian can enlighten us on this (and no, I'm not holding my breath - I
know he's busy.) AFAIK the way mouse/trackball/any-other-pointing-device drivers
work is to generate UI events in response to button clicks and movements.
Mozilla, obviously, can only respond to those events that the OS/UI passes to
it. We are aiming towards a cross-platform solution here and given the
individual idiosyncracies of each OS and its GUI layers it seems (reading
between the lines of comments a bit) that we are responding to that by asking
Brian to code a given set of behaviours to specific button events that we can
reasonably assume will exist on all OS/GUI combinations. I find myself wondering
if this is the right approach. On a windows platform the two main 'enhanced'
mouse drivers are Logitech and Intellipoint. They have similar features, do they
generate similar events to the app when their enhanced features are activated?
Is there any overlap there between events that can be generated within X? on a
mac? I'm sure you can see where I'm going here - If theres no driver support on
a particular platform/GUI combination for the enhanced features why should we
hassle Brian to make mozilla emulate them, and thereby behave differently from
all other apps on the system?
Maybe we should instead ask Brian to just ensure that mozilla *can* respond
appropriately to these events *if* the OS+driver generates them?
As it happens, I *know* the drivers generate events that mozilla can see...
Activating the "universal scroll" (panning) feature on a logitech device does
indeed result in pointing device movement sending scroll-up/down and
scroll-left/right events instead of mouse-move events to the OS and therefore to
the app - the only reason it doesnt work in mozilla is that it isnt the main
window that seems to handle them but an apparently random object contained
within it - unrelated to whether the sub-object is focused or not. To see this
behaviour in action, if you're on a windows system and have a logitech device
just pull up a bugzilla query page (or any other with a lot of widgets) and
activate universal scroll - you'll probably see some random listbox scrolling in
response to your movements, not the main window.
I believe that the mouse drivers enable the panning/scrolling, even inside of Moz.
One time I disabled the mouse driver that is responsible for UI button actions
and it didn't work anymore.
Sorry, I meant "responsible for mouse wheel actions".
yes, thats exactly my point - the 'enhanced' mouse functionality is achieved by
changing the events generated under special circumstances - like enabling a
mouse driver to generate a scroll-up message directly rather than that message
being generated by the scrollbar in response to a click/drag. I'm thinking that
all that is required for these things to work "as advertised" is to ensure that
these events are handled appropriately by the appropriate object. I could be
wrong here but we already have proper behaviour in mozilla for button <whatever>
down, up and drag, for wheel up/down. If we assign a specific role to a given
button on mozilla we're going to break stuff. Similarly if a user assigns
"middle button" to autoscroll in their mouse driver I'd guess that moz wont be
getting middle-button-down/up/drag events so trying to respond to them wont help
much. If middle button triggers autoscroll, what happens to middle button paste
under X? Sticking to the windows world, if I have a device with 4 buttons and
have configured it for buttons 1,2,3 and then button 4 for autoscroll I either
have to reassign button 4 to also be middle button for autoscroll in mozilla and
thereby break it for every app or I have to remember to hit a different button
in one app than in all the others to get the same function. I suspect that most
"general users" would consider that a bug... I'm going to go out on a limb here
and suggest that this MIGHT not be a pure RFE but an indication of a potential
bug in event handling, because these enhanced mouse drivers are generating
events in a way that the design of mozilla did not anticipate.
...With all due respect, Brian, if you're extremely busy, maybe it's time to pass
this bug on to someone else...
you assign pieces of this project to other people (did I ask this before?)
precisely describing all the parameters and the piece of code, perhaps using
some precise method of returning whatever data is necessary?
As I stated in comment 135, I'm planning to throw it on mozdev.org ... I just
had someone email me that they wanted to help, and I will hopefully get it in
the kind of shape where multiple people can work on it at the same time
(requiring cvs tree-management which i will have to read up on). The hard part
has always been keeping it in sync with the current tree. Having its own CVS
tree on mozdev might come in handy since it touches so many files. If anyone has
any experience on CVS tree management (Biesi?) and wants to help me set this up
on mozdev, feel free to email me. I have a couple projects on the site I want to
start, and although I know simple tree management (adding,etc) and client usage,
I don't understand branches very well, and how to keep it in sync with the
Basically, how this works is that you have the initial OS event(s) picked up in
the OS-specific code in widget/src, then it is sent through an object in
widget/public/nsGUIEvent.h to the event-handling code in content/events/src. The
code handles the event and has to do a few things:
First, it changes the cursors according to movement. The cursors are located in
the OS-specific code (On windows windows/resource.h and an rc file that I
believe is located in xpfe/bootstrap) and are assigned XP identifiers that link
into the OS-specific resources.
Secondly, it has to manage the speed of scroll using an algorithm that I divised
but will need to refresh myself on.
Thirdly, it has to display the UI for the autoscroll/panning NSEW artifact(s)
which are located in the chrome under the current theme /themes.
There are of course 2 methods for autoscroll, and therefore 2 different
algorithms needed. I have only implemented 1 so far (except for the NSEW
artifact). It still needs a little work, though, because there are some glitches.
And then, just when we think we have it... We will realize we still have to
implement it on other OSes besides Windows.
>I find myself wondering
>if this is the right approach. On a windows platform the two main 'enhanced'
>mouse drivers are Logitech and Intellipoint. They have similar features, do
>they generate similar events to the app when their enhanced features are
I know reading the comments in this bug are daunting, but I recommend you read
them again (specifically mine)
This was the first real patch I ever worked on other than in Bugzilla, and I had
a lot of learning I needed to do. I was constantly needing help, and it took a
long time. I can probably work on it much faster now, but I will get it onto
mozdev so that it will be worked on by others more than the three times a week I
might get to.
<rant>I am also starting a home-based business for tech consulting on top of the
45 hours I already work. The funny thing is, that even with that I will probably
have more time in a few weeks because of all the other stuff I'm doing now (For
instance I'm still unpacking from college since I'm taking the year off), I'm
setting up a network in the house, training to be a manager, trying to figure
out how to set up a linux firewall/router/gateway, etc etc ;-). Still, I will
make time for this.</rant>
In short, time sucks.
Grrr! I accidentally submitted without finishing the comment (accidentally
pressed enter when changing the whiteboard). I will do the part I was working on
>I find myself wondering
>if this is the right approach. On a windows platform the two main 'enhanced'
>mouse drivers are Logitech and Intellipoint. They have similar features, do
>they generate similar events to the app when their enhanced features are
I know reading the comments in this bug are daunting, but I recommend you read
them again (specifically mine). I did mention we can have different triggers on
different OSes (bug 63712), but we might end up making it the middle mouse
button on all OSes. Perhaps the middle-click function can be replaced with
CTRL-middle click. Still, the possibility of different triggers still exists
for all OSes (including windows) because of the way the OS events handling is
kept separate from the XP event handling.
>They have similar features, do they
>generate similar events to the app when their enhanced features are activated?
>Is there any overlap there between events that can be generated within X? on a
>mac? I'm sure you can see where I'm going here - If theres no driver support
>on a particular platform/GUI combination for the enhanced features why should
>we hassle Brian to make mozilla emulate them, and thereby behave differently
>from all other apps on the system?
Again, as I have said a few times, this won't require any driver support of any
kind. This isn't based on mousewheel, or special mouse buttons.
THE ENTIRE FEATURE IS HANDLED INTERNALLY BY MOZILLA WITHOUT ANY REGARD FOR
SPECIAL MOUSES, KEYBOARDS, ETC ETC.
(caps so no one will miss it ;-)
>As it happens, I *know* the drivers generate events that mozilla can see...
>Activating the "universal scroll" (panning) feature on a logitech device does
>indeed result in pointing device movement sending scroll-up/down and
>scroll-left/right events instead
Mousewheel (What you are speaking of) is something totally independant of this
(I believe that is Bryner's domain). If you don't believe me, get an old serial
3 button mouse and use it with IE. You will see that autoscroll still works
>activate universal scroll - you'll probably see some random listbox scrolling ?
> in response to your movements, not the main window.
A separate issue, and known. Try clicking the page away from a form then using
your mousewheel. This was fixed, btw. If you have a new version of Mozilla, it
might be a regression. Find the bug and indicate what happened.
We are not using IE's autoscroll and even if you somehow turned that off in the
driver, etc... it would have no affect on Mozilla (unless they put a pref into
prefs.js turning it off or something).
We could make anything trigger it, even pressing F12 or something. The only
thing the mouse has to do is move. I imagine all windowing systems can handle
that or Mozilla wouldn't work anyway. ;-)
The only thing at issue is what do we do for people who have only two mouse
buttons (or the stinky Macs with only one) if we are going to use the middle
mouse button as a trigger.
Regarding your last comment...
>Similarly if a user assigns
>"middle button" to autoscroll in their mouse driver I'd guess that moz wont be
>getting middle-button-down/up/drag events so trying to respond to them wont
Unless its a rogue driver, the application gets the chance to override the
driver on the middle mouse click behavior.
>button 4 for autoscroll I either
>have to reassign button 4 to also be middle button for autoscroll in mozilla
>and thereby break it for every app or I have to remember to hit a different
>button in one app than in all the others to get the same function.
If you have a four button mouse, you still have a middle button. The 4th is
usually on the thumb, and the 2nd is considered the middle. In terms of
assigning other things to autoscroll/panning than the default would be another
bug. If after the bug is fixed, you don't like the trigger method, you can
complain in bug 63712 (which this one blocks) to allow people to modify the
trigger. Let's at least get it working first for most cases where people have
middle mouse buttons. After that, allowing alternate triggers will only require
altering the prefs and OS-specific widget/src code and someone else can worry
>I'm going to go out on a limb here
>and suggest that this MIGHT not be a pure RFE but an indication of a potential
>bug in event handling, because these enhanced mouse drivers are generating
>events in a way that the design of mozilla did not anticipate.
I'm going to go out on a limb and say its not, because that's what I believe is
the case from my memory. Maybe if you reassigned the middle click button to be
the letter "F" or something, you would have a problem. As long as you have one
button on your mouse or keyboard that maps to middle click either automatically
(regular 3-button mouse) or through the drivers, you will be fine. We can not
stop rogue drivers from really messing up the mouse buttons before they reach
the OS and create (on windows) a WM_MBUTTONDOWN message instead turning it into
an "F2" key or something. The middle mouse button would (I will go out on
another limb) never be changed automatically by the mouse driver (They would
have to be stupid). If a user decides to get rid of his middle mouse button,
that's not our fault. The only thing we can do is possibly supply an alternate
method or a way to change which key its mapped to.
BTW: Notice that this bug blocks bug 63712. Therefore, when THIS bug is fixed,
that bug will then be worked on. Then is your chance to complain about the
trigger. When THIS bug is fixed (not that one), the only OS it will work on is
Windows - most likely. After bug 63712 is fixed, the feature should work on
every OS (By adding the OS-specific code for each OS). Since I only have Windows
XP, Linux, and FreeBSD (I put it in the electronics club at Rensselaer
Polytechnic Institute almost 2 hrs away nonetheless) - I can't get it working on
every OS by myself. The amount of work to get it working on every OS will
probably be minimal, though, since it will be most likely distributed amongst a
lot of people.
I applied for http://mozscroll.mozdev.org
If all goes well... It should be set up for me by the end of this week and then
I can start putting the stuff in it.
First off, can I applaud Brian for coping with everything else on top of this
and still finding time to keep this one moving. I need to underscore that my
comments were not criticisms of his efforts. I'm not a code-jockey any more - my
c is so rusty that theres no point in me trying to contribute code (if it wasnt
Brian would have been hearing from me a lot more and would have probably been
more pleased to get the messages too ;) ) I was just asking about the design of
this potential feature because what I'm seeing on winME with a Logitech device
raised some questions in my mind. Brian, I *really* appreciate your taking the
time to respond in that much detail.
I do have some additional info to add... First off, I truly wasnt talking about
mousewheel - The TrackmanFX doesnt have a wheel and theres no option in the
driver config to emulate it. Furthermore, changing mozillas settings for
mousewheel response makes no difference to the behaviour I'm seeing - ergo, no
wheelup/wheeldown events are involved in my particular scenario since we already
know mozilla can respond properly to those.
The interesting part, and something that might leap up and bite you later in the
project (which is the ONLY reason I'm mentioning it) is that with the Logitech
drivers you may find things work a bit differently... For example, the app
doesnt need its own NSEW artifacts - Even though moz doesnt scroll in response
to these features the drivers built-in artifacts display just fine, the cursors
change on cue, normal mouse behaviour is inhibited but the app doesnt scroll..
At least some of the behaviour that you're explicitly coding into moz appears to
be work you might be able to avoid... I'd guess this means it MUST be altering
the messages that get into the apps queue from the OS but I havent been able to
verify this explicitly. Anyone know of a good free tool to spy on an apps
message queue in windows so I can really pick this apart? I'd love to resolve
this nagging doubt thats been in my mind ever since I started following this bug
and I'm certain whatever I find out would probably be useful in working on this
David: Hmmm... TrackManFX... Our only option in that case would be to try to
hook in before it gets the messages, or somehow disable this "feature" for
Mozilla if it has some API to do that.
Let's search around the internet to see if there is any info on this.
You can probably find many free tools. Microsoft Visual C++ 6 comes with one -
I called Logitech Tech Support. They didn't have the kind of info I was
looking for but gave me tips on how I could find it by either the SDK or
contacting an engineer with fax.
Logitech SDK: http://developer.logitech.com/sdk/
I am applying to recieve the SDK
If this doesn't help me, then I will have to fax Logitech Engineers at
510-505-0978 and hopefully they will give me the information I need.
Dave: Would this issue apply to the old serial 3-button Logitech Mouseman too
if I got the new Logitech mouseman software?
I might be able to reproduce this for my this mouse I've had for like 6 years.
Created attachment 100068 [details]
Mouse tester - middle click test
Dave: This file is mousetest.exe that I just made.
Run it, and click the middle mouse button with your Logitech Trackman FX in the
black rectange, and see if it says that you clicked your middle mouse button.
If it did, then we probably don't have anything to worry about.
http://developer.logitech.com/sdk/ was the QuickCam SDK :-/
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
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
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....
Since I don't want this bug getting filled with something that is better put in
another bug, all further research on activation by anyone can be put tin bug
63712. I will put Dave's info there.
I have done a lot of updating of http://mozscroll.mozdev.org/ but I haven't
activated it yet.
I added bug 174495 about Dave Booth's issue.
Also, see bug 133054 which will also be dealt with in
*** Bug 176234 has been marked as a duplicate of this bug. ***
*** Bug 176677 has been marked as a duplicate of this bug. ***
I've a logitech mouse and i'm quite hurted too by the poor behaviour mozilla
have regards scrolling mouse actions.. i hope this will be fixed soon.
Area where mouse scroll actions are wrong:
1- Universal scroll don't work
2- YoYo effect when dragging scrollbar and accidently moving wheel in opposite
3- Multiplication of wheel movements (a single click make sometimes the document
to jump to end or start of page)
4- Scrolling on a combo box closes it instead of scrolling contents
This is a classic area where small improvements have an extreme added value for
mozilla user acceptance, please don't give up working on it.
I have found a testcase for replicating 100%
the MouseWheel "inertia" bug.
1) Load a long url page, i.e. www.tomshardware.com
2) Move the mouse from upper side down vertically at slow constant speed
3) *While* the mouse is moving hit the the scroolweel down two or three times
4) The document automatically scroll down to the end of document (*weird*)
It happens only if there are no other scrollable windows on the url document,
for example it does not happen in the mozilla buglist.
Anyone confirm this bug ?
Paolo: Those issues are unrelated to this bug... But I will see if I can find
more info on them in the future.
On another note:
News and updates regarding this and related bugs will more frequently be found
Please keep unnecessary comments down to a minimum.
I came across a way to make this sort of work. I don't know if this is a bug or
a partly implemented version of this feature... Sorry if this has been mentioned
- I tried reading *all* comments, but I can have missed it..
Tested on win2K and winXP with recent builds (1.3a timeframe) with a Logitech mouse.
Steps to reproduce:
1. Make sure the window is not maximized
2. Left-click the scrollbar handle
3. Hold the left mouse button and move to the right of the window
4. While still holding the left button, click (and release) the right button
5. Release left button
6. Move mouse cursor back into the content area
7. Move mouse up and down to scroll
Hmmm...you're right. That does work...but it seems more like a bug to me than
an undocumented feature. You might want to do a search for a bug like that, and
if there isn't one, file a new one.
RE: comment 170 and comment 171
I believe that behavior *is* a bug (or bugs). In fact, I posted the same repro
steps in bug 48037 comment 9.
Other possibly related bugs are:
bug 29300, bug 35191 and bug 157123
Looks like somebody else got it working. I haven't tried it yet:
Wow...besides the lack of a cursor when scrolling, this xpi works pretty darned
well. There could be some performance improvements, but it's not bad at all.
*** Bug 187242 has been marked as a duplicate of this bug. ***
*** Bug 196007 has been marked as a duplicate of this bug. ***
*** Bug 203168 has been marked as a duplicate of this bug. ***
*** Bug 204032 has been marked as a duplicate of this bug. ***
http://autoscroll.mozdev.org is an xpi (extension mechanism) implementation of
the autoscroll functionality.
It is pretty much perfected and is a component in other extensions e.g.
All-in-One extension at http://perso.wanadoo.fr/marc.boullet/ext/extensions-en.html
http://multiscroll.mozdev.org is an xpi implementation of drag and pan. It is
buggy and needs some work.
*** Bug 208109 has been marked as a duplicate of this bug. ***
Sorry, http://mozscroll.mozdev.org is dead at the moment. I'll revive it
eventually, but its not of immediate necessity. Its a toolkit-level solution,
useful for embedding, but there are already 2 projects that offer xpi
functionality for autoscrolling through the chrome, and will suffice for now.
Therefore, about 4 months ago, I diverted my attention to other things. The
Both very good projects, and both much easier to add-on because you don't have
to compile the code or download pre-compiled code from me. Maintaining that
would be extremely difficult for me, so I'm glad the admins of these two
projects have provided the functionality so people will have the functionality.
Therefore, we have the best of both worlds -- and for now regular users (but not
embedders) will be satisfied. That gives me a chance to focus on other things.
Thanks again to the maintainers of autoscroll and multiscroll!
From the mozscroll page: "This is not mozscroll, which is written in native
development cycle - witness this project is pretty much finished already. Still,
when Brian gets Mozscroll finished I'm sure it will be a better result; I fully
support his effort (and hope he may see fit to use some of my code if it's at
After fixing autoscroll for the recent DOM changes, I got hooked and decided to
go and implement RFE 22775 and RFE 133054 - click & drag and panning support.
Note: this is built on and duplicates the functionality of autoscroll - don't
have both installed!"
I'll admit, I originally thought that back 1 year ago these projects were kind
of an insult, like that I wasn't working hard enough, and in fact it did make me
put more time into it. You have to remember, this was around the time that
people were really aggressive in badgering me to work faster. Then, I realized
that they weren't meant as an insult, and simply cause the way I was doing it
wasn't the fastest way to turn out the functionality because it was a more
integrated solution, and therefore much harder to implement within a reasonable
timescale. I guess I'm still learning about project management, which is a bit
beyond the realm of pure computer science and takes experience. :-)
I realized later last year that these projects were a great asset, and hope they
are continued until its finally built-in functionality to the toolkit.
That brings up the toolkit. Due to the direction the XPFE browser is going, I'm
going to find out what I need to do to make this work with the new toolkit, but
I also have to keep it working on the XPFE-based browser as long as its still
maintained because I support the maintenance of the XPFE browser to make the
transition less rocky until we have a full one-to-one functionality and
reliability correspondence (and hopefully more for the new one). In essence, my
work will be doubled, but since I don't have to provide constant downloads
thanks to those two before-mentioned projects, I can focus on programming and
Ed Catmur, and anyone else involved with Multiscroll: I will make extremely sure
that mozscroll will not drop any functionality of multiscroll, and also I'm sure
as you considered on the multiscroll page, that your code will be useful. For
instance, autoscroll getting triggered in the URL bar was a bug we both had. I'm
So, in conclusion, I really recommend trying out the multiscroll code, because
it provides an XPI for autoscroll functionality for anything but embedders or
applications based on mozilla's widget set. Great job!
I'm the filer of Bug 208109, sorry for the dupe :/
I just wanted to chime in that i'm primarily interested in this bug from the
perspective of an embedder, specifically epiphany. Right now I have a patch that
does this specifically in ephy, though I would much prefer it be implemented in
mozilla for consistency amoung gnome apps that use mozilla.
File a bug on http://mozscroll.mozdev.org/, and provide a link to your code, and
i'll take a look at it. Thanks.
The code I currently have is currently heavily based on the epiphany gtk wrapper
around gtkmozembed and hence is not appropriate for mozilla.
*** Bug 209445 has been marked as a duplicate of this bug. ***
*** Bug 209491 has been marked as a duplicate of this bug. ***
*** Bug 209859 has been marked as a duplicate of this bug. ***
*** Bug 210989 has been marked as a duplicate of this bug. ***
*** Bug 215647 has been marked as a duplicate of this bug. ***
*** Bug 218048 has been marked as a duplicate of this bug. ***
This bug is generally been let rot, it seems, because it's a political
Possibly should be put under accessibility where it is clear that implementation
depends on the features supported in the underlying OS. You don't get to be
"Best of Breed" by dumbing down to the lowest common denominator.
I opened bug 219805 as Win32 specific, since that is where the feature is
already implemented in the OS/libraries but Mozilla doesn't make use of it.
For some features -- there needs to be acknowledgement -- as in Accessibilty,
that different OS's have different levels of support. Waiting for something
like this to be implemented on all OS's is certain to prevent it from ever being
Hey, who mass-deleted all emails? Its ok to do that?
Zlixar@InfernalSoul.net, stop mass-removing people from Cc:
*** Bug 219805 has been marked as a duplicate of this bug. ***
We have autoscroll functionality, its just not embedded or embeddable. The
embedded code was what I was working on and obviously haven't worked on in a
while. Anyone is free to pick up my code on http://mozscroll.mozdev.org/
I'd like to clarify that you need to get the extension at
http://autoscroll.mozdev.org/ and boy do we need the extensions to be more
visible. There is a bug on that, isn't there? Most people don't even know the
law (I assume not Bill Law from Netscape?): Windows doesn't have native
autoscroll support for any widgets that are not part of the Windows toolkit.
Therefore, we needed to provide our own support, which we have as both an XUL
extension and hopefully will be embeddable in the future from
http://mozscroll.mozdev.org/ (I imagine AOL and others using Mozilla would like
that so people don't have to install the extension one time for each
*** Bug 220480 has been marked as a duplicate of this bug. ***
*** Bug 225559 has been marked as a duplicate of this bug. ***
*** Bug 229134 has been marked as a duplicate of this bug. ***
*** Bug 233338 has been marked as a duplicate of this bug. ***
*** Bug 238127 has been marked as a duplicate of this bug. ***
*** Bug 245287 has been marked as a duplicate of this bug. ***
I should note that the autoscroll extension doesn't seem to install on mozilla
1.7. There's multiscroll, but it's supposedly buggy and it will only install
This bug is not about the autoscroll extension. In fact, it has little to do
with the autoscroll extension unless two birds could be killed with one stone.
This bug is about XPCOM autoscroll capabilities, which aren't part of Mozilla yet.
kde's konqueror has an "autoscroll" feature activated by shift-arrow .. or was
it alt-arrow... it's shift-arrow
anyway, mozilla already has the smooth scroll.
so.. is this a bug about the "hockey puck" capability, that seems like a hack?
(occasionally the "image not found" picture shows up)
or is this about having autoscroll in thunderbird, and netscape, and mozilla by
The biggest thing about this, imo, is that we have middle mouse click loading
pages on linux... -- that doesn't make sence... luckilly, that's turn offable
in about:config... but autoscroll being on by default is really important for
consistancy across platforms (there are arguments that middle mouse clicking
is supposed to load pages... that's dangerous, and it's wrong)
What its for is autoscroll that is part of XPCOM, meaning its in C++. The
"hockey puck" you speak of is an extension, this is not about the extension.
File bugs on the extension on the bugzilla for http://autoscroll.mozdev.org/
This has all been talked about, and please read every single comment before
commenting, especially the ones by timeless and I.
Implentation details are already discussed and finalized for the C++
implementation of autoscroll except for how to turn off Logitech and Trackman
drivers. And yes, middle mouse page change should be off by default.
Friday 12/11/2004 4.20 pm Melbourne, Australia
I have been using Firefox successfully for two weeks and upgraded successfully
yesterday to the latest version. I have had no problems until today.
Suddenly, the browser window will not open and a message pops up "Alert: Error
launching browser window: no XBL binding for browser". I have tried un-
installing and re-installing without success - same Alert Message pops up.
Embarassingly, I have had to return to Internet Explorer. Please, I would be
most grateful for a solution?
PS I am using Thunderbird successfully.
I'll reply as a comment so that no one else feels the need to respond by comment
or via email. John: XBL binding errors are user-interface issues that don't have
to do with mousewheel scrolling. Please go to
http://forums.mozillazine.org/viewforum.php?f=38 and post your comment there.
Please ask questions there from now on. Thank you.
(In reply to comment #32)
> Brian: I know we all appreciate your work, but would you consider eventually
> having it matter if you hold down the middle key? After all, that is how the
> current NS4.x behavior works, and having to click twice, once to start and
> another time to stop using the panning, is less "zippy" than clicking, holding
> to pan, and releasing. The current behavior in NS4.x works both ways.
Brian: I agree with this. Click on/off Panning is good for scrolling when you
have a lot of distance to cover, but it's not as accurate and you often
overshoot what your looking for because the pan speed is difficult to finesse
with the anchor point.
When using the middle wheel hold-down method: your pan speed is controlled
directly by how fast you drag the mouse across the mousepad. This allows for
finer controll of the pan. The speed controll works the same as using the
pointer to grab & drag the scroll bar, but you can click/hold the middle wheel
anywhere in the window to grab/drag one or both vert & hroz scroll bars at the
I have a Logitech MX500 and my Autoscroll doesn't work in Mozilla 1.5b which is
a real pitty because I use it extensively. It's a massive time/Carpel Tunnel
I would love to see the code from Firefox brought over to Seamonkey.
Apologies for messing with the flags - that was a mistake!
*** Bug 302647 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 304563 ***
This bug isn't a dupe of any other bug. It should be in core.
*** This bug has been marked as a duplicate of bug 242621 ***
I have a good idea for better firefox UI
it's to make middle click assigned to autoscrolling only in the scrollbar region
so that it won't interferes with what ever Linux users do with there middle mouse button
most people are not aware that firefox do have autoscrolling
and even when they know about it, they will disable it back
because we need to copy and paste with middle mouse button
and we do other things with it
middle clicking the scrollbar is not strange it's there in other web browsers like IE and opera
and to make Windows users happy this limiting the autoscrolling region should be only defaults in linux
ie. instead of having autoscrolling on and off
we should have autoscrolling full or smart (or limited)
Limiting scrolling to the scroll bar would be a great step backwards.
It sounds like middle-click on linux is broken.
There's nothing uniq about Linux that isn't the same on Windows.
I use my middle mouse button on Windows to PASTE text just like on linux.
I middle click on links to have them open in background tabs.
It is a constant quirk to make sure I'm not over a link to turn on scrolling, but that's easier than to find the scroll bar -- how would you activate scrolling then the scroll bar is off the window?
What do you think middle click on linux does that it doesn't do on windows?
I regularly have the extension turned on auto-copy selected text, and auto-paste
via middle click -- it's compatible with 'X' (which I also run on Win) and my
remote-term programs that emulate linux terminals by default.
hmmm...I did notice -- on middle click paste, it pastes the text *and* activates
scroll window mode (which I then cancel by clicking...)...a bit uncool...I
didn't think it worked that way -- I thought you had to be over a non-input
window, non-link area to have the auto-scroll activated. But I'm seeing
middle click both paste text and activate autoscroll when it is over a window.
That's less than ideal...but please -- don't even think about limiting AuSc to
the ScrlBr -- that would hurt.
> There's nothing uniq about Linux that isn't the same on Windows.
will, it's desktop integration and user expectations
most linux users expect many things from the middle click
that's why most of them want autoscrolling to be disabled
even if windows version of firefox can do copy/paste in windows with middle click, users in windows are not used to use them, that's why autoscrolling never comes in their way
This is not the place for that discussion, for various reasons, including 1) most of the the ~100 people in CC+votes probably aren't interested; 2) this bug is resolved since forever and none of the suggested changes will be implemented in its context -- suggestions should be filed as separate bugs, but do search first.
> suggestions should be filed as separate bugs
thanks for the advice