(Moved over from a discussion on 20618)... We currently do not recognize the case where the user has set their mouse driver to scroll by full pages instead of by (N) lines at a time. This should be a straightforwad modification - add a boolean to the mousewheel event struct to indicate whether it should be a full page scroll. The XP code to handle full-page scrolling is already in place.

Nominating for beta3 -- causes mousewheel to be nonfunctional in what appears to be a fairly common configuration.

nsbeta3-/future, helpwanted

triaging...

The patch I just attached does a few things: - Adds a new boolean to the nsMouseScrollEvent struct to indicate whether the OS setting is for a full-page scroll - Checks for this condition in the Windows widget code. All other implementations (except OS/2, which already had this mostly right) are hardcoded to 3-line scrolling as the OS setting. - Other minor cleanup of the mousewheel code, mostly whitespace changes (this diff is actually -w [ignore whitespace-only changes] , I also reindented the entire section of nsWindow.cpp according to the modeline). Adding rods and jkobal (for OS/2 code) to the CC... can you review this patch?

Thanks for thinking of us here in OS/2 land, Brian. Two minor corrections: Since you renamed deltaLines to delta in the MouseScrollEvent structure, that change needs to be reflected in the OS/2 code as well. Also, if you wouldn't mind, we have an OnHScroll method for horizontal scrolling that is currently disabled, but should be kept current with the new structure fields; the changes should be identical to those in OnVScroll (this isn't that important though... since we can always make those changes when/if the OnHScroll method is enabled). Would it be possible to add isHorizScroll to the MouseScrollEvent structure like you did isPageScroll, so we can use this event for devices that have scrolling capabilities in both directions (which is what that OnHScroll method is intended to be for)?

That's something I'd planned to do, yes (the horizontal scrolling). I wasn't planning to do it right away, mainly because I didn't know how to get the event for it on Win32, but since OS/2 has it, we can probably make this work. I'd like to do that as a separate bug though. Come to think of it, I'm pretty sure I forgot the deltaLines -> delta conversion on xlib as well. I'll attach a new patch with that fixed.

Looks good to me, although you left "deltaColumns" in a couple of places in OnHScroll, but since that code is all disabled anyway, it really doesn't matter. There are some mice that have two scrolling wheels, and others that have a trackpoint (a little pencil-eraser-like knob that works like a mini-joystick). Also, the IBM ThinkPad 560 has a special key that modifies its trackpoint to do scrolling (which is what prompted us to work on this code in the first place - bug#52458). The Windows code might need to do the same sort of stuff that we have implemented in nsWindow::OnScroll for OS/2 in order to get this to work for both scrolling directions. Would you like me to open another bug for the horizontal scrolling?

Sure, please do. As I mentioned, I'm not sure if it's possible to implement the horiz. scrolling on windows. Windows uses the WM_MOUSEWHEEL message to indicate a wheel movement, and that has no facility for indicating giving a scroll direction.

I don't know how it's done, but I know it's possible <windows>. I also know you were searching...

latest patch wfm.

The message produced is driver-dependent. I would expect a single-wheel mouse to send the WM_MOUSEWHEEL message, but a two-wheel mouse or trackpoint mouse would send probably WM_VSCROLL and WM_HSCROLL messages instead (the ones we have tested do this on OS/2). Currently, the Windows code in nsWindow.cpp doesn't do anything with those messages; if you hook them up like we did in the OS/2 code, you can use the same nsMouseScrollEvent to implement that function. Not only would this allow pointing devices to scroll in both directions, but it would also support any 3rd-party program that sends WM_HSCROLL messages to do scrolling. If you do have to put together another patch for some other reason, would you mind changing deltaColumns to delta in the OS/2 OnHScroll method? Thanks.

New bug #58589 opened to enhance XP scrolling event for Horizontal Scroll.

I tried this patch and it works perfectly for me. r=ben@netscape.com

ok all is good. check it in. xx=mjudge

checked in, thanks all who reviewed/tested

Aw man, it's back! I saw it fixed in 20001103, but now it's returned in 20001105. (Running Win98, IntelliMouse)

Are you sure you didn't get an MN6 build from 11/5 by mistake? No code affecting this was changed at all between those two builds.

I'm not sure how I could tell if it's an MN5 release. I got it from the mozilla.org front page (the "Windows" link under Nightly Builds, gave me a file called mozilla-win32-talkback.zip). Here's what Help|About says: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001105 If I have scwered up, I apologize in advance for wasting your time.

If you point the build at http://www.damowmow.com/mozilla/branch_or_trunk that will tell you whether this is branch or trunk. The link you clicked points to the "latest" subdirectory which may contain either a branch or a trunk build, which is an unfortunate point of confusion, and not just for you. (You can also download builds by going to ftp://ftp.mozilla.org/pub/mozilla/nighly/, where the branch/trunk and actual date/time are encoded in the directory names).