Closed Bug 22775 Opened 25 years ago Closed 18 years ago

"AutoScroll"/Panning support [eg, Mousewheel Click/Drag triggered]

Categories

(Core :: XUL, enhancement, P3)

Product:
Core
Component:
XUL
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 242621
Milestone:
Future

People

(Reporter: mpalczew, Assigned: netdragon)

References

(
URL
)

Details

(Whiteboard: Before commenting, READ ALL (especially netdragon's and timeless's comments) .)

Attachments

(4 files)

This is a picture of the mouse cursors.
708 bytes, image/gif
Details
These are the NSEW artifacts
465 bytes, image/gif
Details
Vertical-only one-dimensional panning cursor
94 bytes, image/gif
Details
Mouse tester - middle click test
140.00 KB, application/octet-stream
Details
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?
Summary: middle button scrolling → [enh] middle button scrolling
Handing over to Don to add to his Browser Wish List pile...
OK, do as elig said, add to don's wish list...
Assignee: shuang → don
Target Milestone: M15
bug 25295 is very similar to this...
Summary: [enh] middle button scrolling → middle button scrolling
Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Move to M16 for now ...
Target Milestone: M15 → M16
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs to Matthew Thomas (mpt@mailandnews.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 elig@netscape.com.)
QA Contact: elig → mpt
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 scrolls faster.
assiging to myself to look at
Status: NEW → RESOLVED
Closed: 25 years ago
QA Contact: mpt → claudius
Resolution: --- → FIXED
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 comments.
whoa, oops. sorry about that. Looks like we read too fast and misintrepeted. resetting milestone for Don (and reopening)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: M16 → Future
Same as bug 31412?
*** Bug 31412 has been marked as a duplicate of this bug. ***
Blocks: 55696
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.)?
No longer blocks: 55696
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 Windows-specific problem.
OS: All → Windows 95
Hardware: All → PC
Summary: middle button scrolling → MS Intellimouse "AutoScroll" feature doesn't work in Moz
Also marking '4xp' since AutoScroll is reported to work in Nav4.x.
URL: n/a
Keywords: 4xp
Well, autoscroll works fine for me provided you don't get bitten by a focus bug. Over to Bill for future evaluation ...
Assignee: don → law
Status: REOPENED → NEW
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 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.
Assignee: law → bryner
Keywords: helpwanted
OS: Windows 95 → All
QA Contact: claudius → sairuh
Hardware: PC → All
Summary: MS Intellimouse "AutoScroll" feature doesn't work in Moz → [RFE] "AutoScroll"/Panning support [eg, Mousewheel Click/Drag triggered]
Target Milestone: Future → ---
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. Thanks!
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.
QA Contact: sairuh → lorca
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.
URL: http://msdn.microsoft.com/library/boo...
Component: User Interface: Design Feedback → XP Apps
reassigning to boberb@rpi.edu since he offered to take it.
Assignee: bryner → boberb
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
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 timeless@mac.com 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 slipping etc) 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.
david@2gen.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.
Whiteboard: Read 2000-12-04 19:05 before commenting.
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]
Summary: [RFE] "AutoScroll"/Panning support [eg, Mousewheel Click/Drag triggered] → [RFE] AutoScroll/Panning support for middle mouse button
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.
Blocks: 63712
Summary: [RFE] AutoScroll/Panning support for middle mouse button → [RFE] "AutoScroll"/Panning support [eg, Mousewheel Click/Drag triggered]
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: Autoscroll mode: 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. Panning mode: 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 triggered. ;-) 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 : http://www.microsoft.com/products/hardware/MOUSE/intellimouse/sdk/ Intellimouse Messaging: http://www.microsoft.com/hardware/mouse/intellimouse/sdk/sdkmessaging.htm I will assume logitech uses the Microsoft standards for the Windows operating system. 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 taking control. 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 then... 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) 10 16 50 69 100 277 200 1111 500 7000
*** Bug 64009 has been marked as a duplicate of this bug. ***
*** 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 appropriate?
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 it yet. 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 javascript chrome function. By definition, I believe (correct me if I'm wrong) 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 was panning? 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.
QA Contact: lorca → gerardok
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 scrolling.
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
Target Milestone: mozilla0.9 → mozilla0.9.1
*** 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.
Target Milestone: mozilla0.9.1 → ---
I am planning to work on this. I need to know more info on how to hook messages, though.
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 mozilla. 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 upset because: 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 with mozilla 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 handling queue: NS_MOUSE_APS_TRIGGER_ACTIVATE NS_MOUSE_APS_TRIGGER_DEACTIVATE 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 trigger. 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.
Keywords: mostfreq
*** Bug 85176 has been marked as a duplicate of this bug. ***
Status report: 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.
Keywords: helpwanted
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...
Yes. A=Autoscroll B=Panning Middle mouse button = default trigger for windows. Please call it the trigger from now on and not the middle mouse button (for xp sake). 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 timeless@mac.com 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*
Whiteboard: Read 2000-12-04 19:05 before commenting. → Before commenting, *Read* the whole bug *especially* 2000-12-04 19:05 and 2000-12-22 08:10
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 re-explain it. 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 pref in.
Whiteboard: Before commenting, *Read* the whole bug *especially* 2000-12-04 19:05 and 2000-12-22 08:10 → Before commenting, *Read* the whole bug.
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.
Whiteboard: Before commenting, *Read* the whole bug. → Before commenting, READ ALL. I am sick of repeating.
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 :)
Whiteboard: Before commenting, READ ALL. I am sick of repeating. → Before commenting, READ ALL.
Target Milestone: --- → mozilla1.0
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 a double-click).
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 bookmarklets (http://www.bookmarklets.com/). 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 originally started working on this in XUL and javascript and decided that was no 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 bug 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 attacks again. 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.
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.
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 (http://www.mozilla.org/roadmap/mozilla-1.0.html Work on this bug will continue but it will not be checked in until after 1.0
Target Milestone: mozilla1.0 → mozilla1.0.1
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. Steve
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.
<RANT> 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. </RANT>
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. <opinion ends> Steve
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 frustration.
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 Intellipoint driver. 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. Steve
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?
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 ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch06d.asp ) 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.
Target Milestone: mozilla1.0.1 → Future
*** 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.
Whiteboard: Before commenting, READ ALL. → Before commenting, READ ALL (especially netdemon.
Homer said: ...With all due respect, Brian, if you're extremely busy, maybe it's time to pass this bug on to someone else... Steve said: 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? .. My responses: Homer, Steve: 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 Mozilla tree. Dave: 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. Dave cont'd: >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? 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 before: Dave cont'd: >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? 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 >help much. 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 about that. >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.
Whiteboard: Before commenting, READ ALL (especially netdemon. → Before commenting, READ ALL (especially netdemon's and timeless's) .
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.
Whiteboard: Before commenting, READ ALL (especially netdemon's and timeless's) . → Before commenting, READ ALL (especially netdemon's and timeless's comments) .
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 project.
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 - Spy++.
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.
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 options.
More logitech data.. I grabbed a download of winspector and have been poking around the UI with the logitech scrolling. my "test app" was moz 1.1, "test pages" were the mozilla.org start page and the bugzilla query page. I also played with other apps to look for behaviour differences. MS-like autoscroll (office-compatible checkbox on): Does nothing for mozilla or any other app but send middle button events. Its therefore reasonable to assume that any app other than those specifically coded to autoscroll in response to the middle button will not respond to this. Under these curcumstances the NSEW artifacts etc must be explicitly added to the app. This breaks autoscroll for almost every app other than MS products. Logitech autoscroll (office-compatible checkbox off): Works (sorta) for pages in mozilla provided there are no scrollable subwindows - like the list boxes in a bugzilla query, for example. Displays artifact by creating a window of class "Logitech ScrWnd" (presumably the artifact itself) at the cursor position which then grabs the focus, changes the cursor and sends SBM_SETSCROLLINFO messages to the scrollbars of the previously-focused window to move its contents around. Seems to never really detect a horizontal scrolling capability in mozilla, even if there is a horiz scrollbar in the main window so only ever shows the NS artifact and cursors. NS scrolling works as expected though. The problem here is that if there are scrollable subwindows (the bugzilla query page is a good example) the scrollbar that gets the SETSCROLLINFO messages is usually the one attached to the nearest listbox to where the artifact is displayed. Mozilla is unique in this behaviour. If I do the same thing in IE the "right" scrollbar is moved. Other windows with scrollable widgets also behave as expected. The "real window" scrollbars get these messages, not scrollbars attached to a contained widget. universal scroll (checkbox doesnt seem to make a difference): never touches the main window, only time you see any scrolling effect is if there are scrollable widgets. Scrolls the widgets not the main window. Again displays artifacts by creating a window at cursor position that grabs the focus and sends events to scrollbars. Works just fine in any other app though. This looks very much like the logitech drivers are quite capable of scrolling mozilla as-is, so long as they send their events to the right component of the right window. The only real difference I can find to explain it is that the structure of the widget sets and window components are completely different for mozilla to every other app... I'd presume that this is due to mozillas cross-platform heritage. The logitech drivers seem to be relying on certain win32-specific window styles that are not strictly relevant to the object model and widget sets used in mozilla. Hate to say it, Brian, but this one looks like its gonna hurt....
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.
URL: http://msdn.microsoft.com/library/boo... → http://mozscroll.mozdev.org/
No longer blocks: 88820
No longer blocks: 63712
Depends on: 63712
I added bug 174495 about Dave Booth's issue. Also, see bug 133054 which will also be dealt with in http://mozscroll.mozdev.org/
Alias: Autoscroll
Summary: [RFE] "AutoScroll"/Panning support [eg, Mousewheel Click/Drag triggered] → "AutoScroll"/Panning support [eg, Mousewheel Click/Drag triggered]
*** 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 direction 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. Regards,
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 on http://mozscroll.mozdev.org/ Please keep unnecessary comments down to a minimum.
Blocks: majorbugs
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: http://dialspace.dial.pipex.com/town/pipexdsl/o/aoos87/sa/autoscroll.html
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. ***
pü9j+pjü
*** 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 solutions are: http://autoscroll.mozdev.org/ and http://multiscroll.mozdev.org/ 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 code. Multiscroll uses javascript, chrome and xpi as these make for a far faster 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 all appropriate!). 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 documentation. 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 sure the solution is consistent between javascript and XPCOM. 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 mess. 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 implemented.
Depends on: Autoscroll/win32
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. ***
No longer depends on: Autoscroll/win32
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 extensions exist. 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 Mozilla-based application.
*** 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 system-wide.
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 default? -- 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.
Whiteboard: Before commenting, READ ALL (especially netdemon's and timeless's comments) . → Before commenting, READ ALL (especially netdragon's and timeless's comments) .
Friday 12/11/2004 4.20 pm Melbourne, Australia Dear "Help", 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? John Mallinson 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.
Product: Core → Mozilla Application Suite
no comments
No longer blocks: majorbugs
(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. > Thanks! 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 same time) 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 saver :)
I would love to see the code from Firefox brought over to Seamonkey.
Flags: blocking-seamonkey1.0a-
Apologies for messing with the flags - that was a mistake!
Flags: blocking-seamonkey1.0a-
*** Bug 302647 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 304563 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 19 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
This bug isn't a dupe of any other bug. It should be in core.
Status: REOPENED → ASSIGNED
Component: XP Apps → XP Toolkit/Widgets
Product: Mozilla Application Suite → Core
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → DUPLICATE
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 http://fedoraproject.org/wiki/FWN/Issue138#Firefox_Mouse_Woes 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 http://fedoraproject.org/wiki/FWN/Issue138#Firefox_Mouse_Woes 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 https://bugzilla.mozilla.org/show_bug.cgi?id=452606
Alias: Autoscroll
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: