The Intellimouse Explorer (I scratched the label off of mine) has a forward and a backwards button that the user can access using their thumb. Microsoft built in compatibility so that it controls backwards and forwards in the Internet Explorer browser. I would like this same functionality in mozilla.

Here is the MSDN API calls. http://msdn.microsoft.com/library/psdk/winui/mousinpt_6pv7.htm Here is a picture of the configuration dialog box. Hope it helps. http://www.shwag.org/mouse.jpg

*** Bug 31798 has been marked as a duplicate of this bug. ***

Reasonable RFE. Confirming and assigning to nobody@mozilla.org (where all helpwanted bugs live) Adding helpwanted to keyword.

bryner, I know it's not mousewheel but is it something you would be willing ot look into/tackle?

This is kind of an interesting issue. I believe the headers on the Mozilla build machines would have to be updated in order for them to contain the WM_APPCOMMAND message.... I have no way to test this myself though, so I'm probably not the person to implement it.

Bryner, I would be more then happy to work with you and report back to you with whatever information you need for testing.

I'm not a very good programmer, but from this description it does not look like it is -required- to impliment the WM_APPCOMMAND. Looks like you just simply have to listen for the WM_XBUTTON* and WM_NCXBUTTON* messages ... and then call up backwards or forwards on the browser. --excerpt from MSDN-- "The Microsoft IntelliMouse Explorer is a mouse with five buttons. The two new mouse buttons (XBUTTON1 and XBUTTON2) provide backward/forward navigation. The window manager supports the new mouse hardware by introducing the WM_XBUTTON* and WM_NCXBUTTON* messages. The HIWORD of the WPARAM in these messages contains a flag indicating which X button was pressed. Because these mouse messages also fit between the constants WM_MOUSEFIRST and WM_MOUSELAST, an application can filter all mouse messages with GetMessage or PeekMessage. In addition, the WM_APPCOMMAND message supports these mouse buttons."

sorry...I meant to type *-NOT-* required.

*** Bug 31419 has been marked as a duplicate of this bug. ***

*** Bug 34898 has been marked as a duplicate of this bug. ***

*** Bug 31419 has been marked as a duplicate of this bug. ***

On the Mac, the default Intellimouse settings map those buttons to "back" and "forward", and they are implemented by faking the key events corresponding to the keyboard shortcuts. I verified that mozilla is getting these events on the Mac when the buttons are pressed, so this should come for free on Mac once keyboard shortcuts are in place. This should be changed to platform "all." Marking the depende

Ben says this is now working.

*** Bug 54336 has been marked as a duplicate of this bug. ***

this doesn't work with the 2000110104 trunk build on win2k. reopening this bug & adding the regression keyword.

cc'ing aaron in case this interests him wrt accessibility.

*** Bug 64008 has been marked as a duplicate of this bug. ***

I don't know if we can use WM_APPCOMMAND, nor WM_XBUTTON*, nor WM_NCXBUTTON*, etc. Looking at the message descriptions, all of them require Win2000 or WinMe. Here's the link again: http://msdn.microsoft.com/library/psdk/winui/mousinpt_6pv7.htm

*** Bug 64485 has been marked as a duplicate of this bug. ***

*** Bug 66045 has been marked as a duplicate of this bug. ***

*** Bug 68585 has been marked as a duplicate of this bug. ***

It looks like standard practice in XFree86 is for these buttons to generate events on buttons 6 and 7 (see Bug 64485). Currently these buttons seem to behave exactly like button 1, but it would definitely be nice to have the back/forward functionality.

I got tired of clicking the side buttons on my intellimouse and having nothing happen, so I invested my evening in fixing this bug. The forthcoming patch will cause the mouseup/mousedown events to fire for these buttons, and will set event.button to 3 or 4.

*** Bug 72981 has been marked as a duplicate of this bug. ***

sorry, please ignore that last patch. It's broken. New one in a minute.

Any idea if this works for free under earlier versions of Windows, such as 95 and NT4?

There is a major problemo with that patch, which is that if you have the intellimouse driver running in a certain mode, it will send the Alt-Left/Right keystrokes in addition to the mouse click events, so in Navigator you would actually go back/forward 2x per click. Yuck. Now that I figured out how to get my driver to send the Alt keystrokes to Mozilla, I'm less motivated to work on this.

can you just make this a pref? so if people who don't have emulation or don't want to use it can use your code.

*** Bug 79023 has been marked as a duplicate of this bug. ***

i am using 2001050520 and intellimouse support is still missing why don't you just put the patch into the next build of mozilla?! it would be very nice because im really missing the two buttons...

http://msdn.microsoft.com/library/psdk/winui/windows_9ojd.htm LRESULT CALLBACK WindowProc(...) Return Values If an application processes this message, it should return zero. -If we behave correctly, then it would seem that the os shouldn't be sending us the key emulation. the api is defined for w2k, so the question is what do the 9x/nt4 mouse drivers do...

*** Bug 80675 has been marked as a duplicate of this bug. ***

buttons wfm on Win2K 2001051604

11 dups. Marking mostfreq.

*** Bug 84621 has been marked as a duplicate of this bug. ***

It would appear at least on W2K - 200106320 that the button forwards and backwards buttons are working. Except if you click forward (no screens forward) or backwards when on the first screen it crashs Mozilla!!!!

it doesn't work for me with win2k - but i haven't the intellisoft installed since it isn't needed for ie under 2k! probably thats the reason it doesn't work at all?! but it would be cool if you could get it working so the users don't need to install the intellimouse software

*** Bug 85658 has been marked as a duplicate of this bug. ***

hewitt, What is the status on this bug? Do you think that there is a way to detect if intellimouse isn't installed and handle the WM_XBUTTON messages, otherwise handle the WM_APPCOMMAND message? What happens on other 5 button mouses other than intellimouses?

*** Bug 88645 has been marked as a duplicate of this bug. ***

It looks like "back" command works with logitech mouse in mozilla 0.9.2 and logitech drivers v9.28b44 (available on their FTP site ftp://ftp.logitech.com/pub/techsupport/mouse but not on the web).

I have a patch and permission for checking in. Please assign to me.

3/22 patch is not smart. Because these patches do not contain Natural Keyborad Pro's Hot Key support.

add me

*** Bug 89192 has been marked as a duplicate of this bug. ***

can you only make changes if you are assigned to do it?

Being that the IntelliMouse software is created for every major distribution and XFree86 is on every other distribution that Microsoft won't support, Wouldn't it make better (and save work) to forward such requests to the XFree86 team and have them implement functionality to map buttons 6 and 7. This way the mozilla team doesn't have to deal with it (and can concentrate on major bugs) and it can be implemented by everyone with any common sense. I personally run Win2k & Linux and under Win2k it works if you have the IntelliMouse software, it is a free download from Microsoft so this really shouldn't be a problem for Mozilla Users under windows. As for linux this is a major annoyance because I've gotten used to the buttons and I can't find a fix anywhere. I've put my blame on the XFree86 team but with time and enough bitching from me and the mozilla community something should happen.

Buttons 6 and 7 are mapped for me in X using: Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Device" "/dev/mouse" Option "Protocol" "ExplorerPS/2" Option "Emulate3Buttons" "off" Option "Buttons" "7" Option "ZAxisMapping" "6 7" EndSection xev shows that they are mapped when clicked, but Mozilla doesn't process the 6 & 7 clicks.

i know many people who don't want to install the intellipoint software. it is plain unuseful, another fat driver making windows start slower and work slower, i wouldn't just make it easy by saying all windows users should have it installed. other mice that also have 5 buttons don't work with the intelli drivers so we've got the same problem again.

Oops, sorry forgot to add that you need to put the following line in your .xinitrc: xmodmap -e "pointer = 1 2 3 6 7 4 5"

Whis is bug 20618 (a scroll wheel problem) marked as "major" bug, but this one is only an "enhancement"? I find these two problems to be on the same level. And I agree with Mr. Glatt.....the majority of users do not want/need to install the intellipoing software (esp for one application).

*** Bug 93158 has been marked as a duplicate of this bug. ***

Could anyone clarify what the status of this bug, with regards to buttons mapped to 6 and 7 under X, is? I'm trying to add support for buttons 6 and 7 to go back and forward in the Galeon browser, which uses the GtkMozEmbed widget, but it sounds from users like the events that are getting passed to the callback are claiming to be from button 0 instead.

I can implement this for windows.

This feature has been working on my RedHat 7.1 Linux system with 0.93, but is broken in 0.94! Interestingly the Windows build works (with loaded point32.exe).

relinquishing this one to the masses...

Anything new about this "bug"? I missed this feature in the actual build.

This works for me on win2k build 20011113.. and Intellimouse Explorer USB

I assume you have IntelliPoint software installed, the goal is to do it without depending on this software...

m_kato: About your patch, which I only had a chance to take a quick look at... - There's some indenting weirdness in |case WM_APPCOMMAND| in nsWindow.cpp - The NS_NAVIGATE_COMMAND processing seems extensible enough to handle enhancements such as adding support into mail (bug 110749). Am I reading it properly? - The documentation on MSDN wasn't too clear. What happens for all the people that have the software installed already and it works fine for? I assume that the driver is basically simulating an Alt+Left Arrow keypress. Does returning TRUE in response WM_APPCOMMAND stop the driver from doing this? (the link that timeless posted is broken)

New URL: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/mousinpt_6jz9.asp (It really urks me when Microsoft changes their site layout and doesn't redirect) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/keybinpt_8sbo.asp Dean: From the above url, it seems like if we return true, the driver will know we performed the behavior... Otherwise, for the case of navigation, it will probably ignore it because Mozilla has focus. Don't you think that we should also have a preference that allows us to work independently of the windows settings and use the XBUTTON messages? This might come in handy if people want to have it go forward and back, yet they use their XBUTTONs for something else (such as mapped to the F11 key for gaming or something).

Brian: Thanks. I missed this part: "Unlike other windows messages, an application should return TRUE from this message if it processes it. Doing so will allow software that simulates this message on Windows systems earlier than Windows 2000 to determine whether the window procedure processed the message or called DefWindowProc to process it." I think that on Windows, at least, we should stick to what's set in the control panel. In my experience, Windows users like to set things in one central place and have it take effect everywhere. Which raises a (what I think is) valid question. Since there are patches here for Windows, should we make this bug specific to Windows and split off bugs for Mac and Linux?

m_kato: If you could post another patch that's current against the trunk, I'll take it for a test drive.

dean: Split off bugs would probably would be a good idea not to resolve this fixed until the split off bugs are also fixed. Of course, the windows - specific code should be checked in. (IMHO) I don't agree, though, that Windows users want the same behavior on all applications for the two extra buttons. For instance, in Counterstrike - I would want the two extra buttons to reload or pick up weapons. Currently, Counterstrike doesn't recognize those two buttons, so I have to map that functionality to Function keys. This messes up those buttons for browsing. IE, therefore can't go forward and back with those two buttons - which stinks! Netscape shouldn't follow the same mistake of doing what the entire system does. Even Counterstrike should handle the keys differently. IMHO - those extra buttons should be App-specific. Now, if the user didn't want Netscape to interfere with those buttons (say it brought up an application or something), then all they would have to do is tell prefs that they want the buttons to be handled in the way defined in the control panel. It should also be this way by default.

dean: are you willing to take this bug to get it off the nobody radar?

brian: if you can tell me how to disable the pseudo-button support in my driver without uninstalling it, then sure.

For my mouse (Intellimouse Explorer), I just go into the control panel under Mouse. If you don't have anything there that helps you disable, you might have to download the software that lets you do it for your mouse (such as the Intellimouse Explorer software). What mouse do you have? Or, do you mean programatically? I believe we just handle the message and it blocks out the driver. I did something similiar for Autoscroll/Panning. What do you think?

OK, I'll take this. My plan is to take m_kato's patches and make sure they work. From looking at them, they should. I'll update them to the trunk. Is there anything else I should do?

Note to self: use NS_NAVIGATE_START instead of NS_ACCESSIBLE_START.

Brian: Can you file what you said in comment 68 as a separate RFE?

Up-to-date patches, with a few changes. Not that much different here, really. I changed NS_NAVIGATE_* and nsNavigateEvent to NS_APPCOMMAND_* and nsAppCommandEvent, respectively. I'm open to different ideas for naming. I know that I added return values of PR_TRUE to both nsEventStateManager and nsWindow.cpp, I did that on purpose. Right now neither DispatchWindowEvent() returns a value that we can reliably use as true or false to determine if the message was handled, so for now it's left up to the WM_APPCOMMAND processing to return PR_TRUE or PR_FALSE. Note: In the patch to nsEventStateManager, I moved the declaration of targetContent in the NS_MOUSE_ENTER processing inside the "if" because I was getting a compiler warning.

This is right now a fix for Windows only. Once we get this in, other platforms can do whatever processing they need to and end up dispatching NS_APPCOMMAND_*, similar to the changes in nsWindow.cpp. This will be handled by nsEventStateManager.cpp. Once the fix for Windows gets checked in, I'd like to open separate bugs for the implementation on specific OSes, dependent on this bug.

cc:ing a few people that I know can't get enough of this stuff, in hopes that they want to offer some comments on my patch.

I filed the seperate RFE - bug 126161. The patch looks generally good to me although I didn't take a really long look at it. Looking at it, though, makes me remember that nsEventStateManager is becoming huge and needs to be modularized and cleaned up.

will it works for the 1.0 version? i've just downloaded 0.9.9 and the forward/backward buttons don't function (win XP/ dexxa wireless-optical mouse). regards

This bug is over two years old. When the mouse came out, MS put the feature in IE right away. Think it will make it into 1.0 ? Give me a break! This project is opensource. That means that we don't have to worry about the details. The community will pick up the slack.

works just fine here (and always did) with Intellimouse Optical USB. Just configure the buttons in mouse control panel to do forward and backward.

Artem, You're missing the point of this bug. Mozilla should be able to utilize the Forward and Back Button *without* needing to install the Intellimouse drivers. (as IE can..)

Hmm, so it does! Confirming WFM 2002040903 on Win2k, using Intellimouse Optical [*] with driver version 4.0.0.657 (you can see your driver version in Control Panel -> Mouse -> Hardware -> Properties -> Driver). [*] "Intellimouse Optical" doesn't refer to just any MS optical mouse, but specifically this one: http://www.microsoft.com/hardware/mouse/io_info.asp

Also, to add to WD's comments -- this bug pertains to non-Windows operating systems.

Is there any chance of getting this patch in a compiled format? I don't compile in Windows.

My hope on this bug is that on Windows it either A) uses the method selected in control panel under mouse settings (By handling back/forward messages) B) Just the forward and backward (by handling the button messages) C) Both D) None depending on values in prefs. For other oses, can people dig up info on 5 button mouses? I just set up X Windows with Intellimouse Explorer, but I have no clue on how applications would use this, or even how to set it up to recognize the 2 extra buttons.

A Linux system with 5(7) mouse buttons (i own a MS IntelliMouse Optical) that is set up like described in http://www.mandrakeuser.org/docs/xwin/xmouse.html#button should be able to use these buttons *but* afair <=0.96 was the last version where this worked on Linux. Currently i use Galeon's mouse gestures as a workaround... Any ideas?

could someone nominate this for nsbeta1 and/or mozilla1.0 ? we should really get this for 1.0.

Why just do not install the mouse driver? It works for me for 1.5(?) year. I just install the Intellipoint driver, set this up and all works fine in the whole windows, not only in browser. Drivers: http://www.microsoft.com/hardware/mouse/download_ns.asp

Eugene, Again, this is to use the back and forward buttons on Windows _without_ the drivers (like ie), and MORE importantly on other operating systems than _Windows_ (like Linux, FreeBSD, Solaris, etc.) using Mozilla and mice with 7 buttons.

*** Bug 133529 has been marked as a duplicate of this bug. ***

*** Bug 151215 has been marked as a duplicate of this bug. ***

*** Bug 151232 has been marked as a duplicate of this bug. ***

*** Bug 118754 has been marked as a duplicate of this bug. ***

Mozilla is universes better than Internet Explorer, but I just can't get myself to give up the quick-scroll, and forward and back buttons! I think this would make a lot of people feel the same way. If it isn't that hard to fix, this would make me have the final switch. Great product, & thanks 4 reading! -Randy

Randy: As mentioned in comment #84, you can already get back/forward functionality if you install the Intellimouse drivers. Of course, this bug still exists in the hopes of getting that functionality without requiring the specific drivers to be installed.

And as I said in comment 76 through comment 78, this work is basically done for Windows. If there's any interest and potential of an actual review, I can code up a patch against the current trunk. If nobody's going to review it, I've got better things to do with my time.

Yes, yes, please implement this. Windows-only is okay. We can make it multiple-platform later. Not sure whether it could get into 1.1 at this point. Maybe 1.2?

I know this feature is wanted by end-users, so please don't add "me too" comments. What I need before I go spend time re-coding the patch against the current trunk is someone to step up to say they'll review it, but more importantly an indication from the powers that be that this is something that is worthwhile checking into the trunk.

saari: is this something we want for embedding? bryner: what do you think of this patch?

*** Bug 162209 has been marked as a duplicate of this bug. ***

*** Bug 143380 has been marked as a duplicate of this bug. ***

*** Bug 164069 has been marked as a duplicate of this bug. ***

*** Bug 165828 has been marked as a duplicate of this bug. ***

*** Bug 167314 has been marked as a duplicate of this bug. ***

*** Bug 173970 has been marked as a duplicate of this bug. ***

*** Bug 174478 has been marked as a duplicate of this bug. ***

*** Bug 170647 has been marked as a duplicate of this bug. ***

To add a bit of information to what looks like a bit of a dead "bug" is that I have a Logitech Cordless Mouseman Optical which has a "back" button that works in Explorer but doesn't work in Mozilla under Windows XP SP 1. I did a quick check with WinSight and when I click with that button on the browser windows I get the following Mouse messages sent to it: WM_MOUSEACTIVATE Sent WM_020Bh in Client hwnd 0045018E WM_SETCURSOR Sent WM_020Bh in Client hwnd 0028018A WM_SETCURSOR Sent WM_020Ch in Client hwnd 0028018A Now, I am no expert, but those seem to be the base button events sent inseatd of the normal left click and right click. Dean, I don't know if you patch specifically traps those events or not, but if it doesn't, it seems for the Windows environment, those would be the ones to re-act to. The Logitech mouse doesn't have a forward button, so I can grab the WM Messages for those.

*** Bug 174864 has been marked as a duplicate of this bug. ***

Cool. Bug 174864 helped me realize that the way to disable the "mock" support for back and forward from the mouse is to kill the point32.exe task. Without point32.exe running, only native support for the mouse will work.

*** Bug 175494 has been marked as a duplicate of this bug. ***

*** Bug 176978 has been marked as a duplicate of this bug. ***

*** Bug 177016 has been marked as a duplicate of this bug. ***

Wow. Its been about two and a half years since I submitted this bug. Amazing how time flys. I just want to appologize to those whose time has been consumed by this bug. I thought adding in forward and backwards mouse buttons would have been simple. I never would have anticipated it would have taken so much time and resources. But thanks to all!

*** Bug 177550 has been marked as a duplicate of this bug. ***

*** Bug 178527 has been marked as a duplicate of this bug. ***

Re: comment #100: There have been 36 duplicates of this bug so far, not counting all the people like myself who bothered to search for the bug before filing. What more of an indication do you need?

Brian: What part of my comment wasn't clear? "I know this feature is wanted by end-users ... but more importantly [I need] an indication from the powers that be that this is something that is worthwhile checking into the trunk."

So what have "the powers that be" said in the last 4 months?

Dean: Why wouldn't it be checked into the trunk? Have you asked to get the code reviewed yet?

*** Bug 179904 has been marked as a duplicate of this bug. ***

Brian: I asked for comments back in comment 78 and didn't receive any besides yours. Jag asked for a couple of opinions in comment 101.

Nobody has offered any, though, so they obviously don't have any comments or aren't paying attention. Would you mind emailing those whom you think need to approve this so that we can get this fix checked in, this 3-year bug closed, and stop all the duplicates form coming in?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/mouseinput/aboutmouseinput.asp I think that sites more useful. The old one went bad.

Brian: read comment 98

I don't know the trunk so well, so I don't think I'm the right one to review it. I did take a look at it, though and it looks pretty good. Once concern I had was that you are catching SEARCH, FAVORITESm and HOME and returning PR_TRUE, signaling that you've handled those events but you're not actually handling them. If I have installed drive software to handle those events, then won't this prevent that from handling it as well?

Good point. Actually, should there be code in there to handle those at all, or should it be taken out? My thinking at the time was that SEARCH could go to the default search page, FAVORITES could open Manage > Bookmarks, and HOME could open the user's home page. I think that's probably why I had them returning PR_TRUE, but I guess I never finished that.

Dean: Be advised that there are other bug reports open requesting exactly the sort of handling you had considered: bug 64371 for Windows; bug 66519 for X. Perhaps this code should stay in. If it is removed, perhaps the diffs should be attached to one or both of these reports in case it needs to go back in again later.

Comment on attachment 70052 [details] [diff] [review] cvs diff -u mozilla/widget Looks good

Comment on attachment 70051 [details] [diff] [review] cvs diff -u mozilla/content/events/src This patch doesn't apply to the trunk anymore. Minor changes needed, I'll post new once I update my tree.

Comment on attachment 70051 [details] [diff] [review] cvs diff -u mozilla/content/events/src Argh, this patch applies fine. Rod can you r=? Brian can you sr=?

This patch applies cleanly to the trunk.

Comment on attachment 106886 [details] [diff] [review] cvs diff -u mozilla/widget Carrying forward bryner's sr=. The only changes from the last patch are that Makoto Kato's name didn't get added to the contributors list in nsWindow.cpp, and that NS_APPCOMMAND_EVENT is #defined as 24 in nsGUIEvent.h since NS_POPUP_EVENT is 23.

Comment on attachment 106886 [details] [diff] [review] cvs diff -u mozilla/widget >+ switch (appCommand) >+ { >+ case APPCOMMAND_BROWSER_BACKWARD: >+ case APPCOMMAND_BROWSER_FORWARD: >+ case APPCOMMAND_BROWSER_REFRESH: >+ case APPCOMMAND_BROWSER_STOP: >+ case APPCOMMAND_BROWSER_SEARCH: >+ case APPCOMMAND_BROWSER_FAVORITES: >+ case APPCOMMAND_BROWSER_HOME: >+ DispatchAppCommandEvent(appCommand); >+ // tell the driver that we handled the event >+ result = PR_TRUE; >+ break; >+ } >+ // default = PR_FALSE - tell the driver that the event was not handled >+ break; Actually, I've thought more about comment 128, comment 129, and comment 130. I'd like to comment SEARCH, FAVORITES, and HOME out of here until we actually handle them. I'll leave the code that returns PR_TRUE in nsEventStateManager.cpp but it will just never be called, so that it's not lost in the future. bryner, are you OK with that or would you rather I do it another way?

Comment on attachment 106886 [details] [diff] [review] cvs diff -u mozilla/widget change inclued to included and I think commenting out the HOME etc. is a good idea

That's fine with me, too. BTW- in nsEventStateManager, I think you're missing a break after you handle case NS_APPCOMMAND_STOP.

Comment on attachment 70051 [details] [diff] [review] cvs diff -u mozilla/content/events/src Oops, didn't mean to clear that.

when this gets checked in, please file new bugs to implement this in other toolkits (at least mac, gtk, gtk2)

Brian's right in comment 138 - I should add a break in my outer case in nsEventStateManager.cpp. Really minor change. I just need a review on the changes to nsEventStateManager and then this patch can go in.

Maybe this should be filed as a seperate bug, but i guess it's also relavent here: If you go to Print Preview and click either of the intellimouse back/forward buttons, you get an error saying "The document cannot change while in Printing or in Print Preview". Maybe the buttons should be hooked up to switch pages (forward/backward) or just disabled altogether. This is with the driver software installed on Moz 20021016 and Phoenix 20021119. To reproduce: 1. Open Moz. 2. Go to a page. 3. Go to another page (so there's something to go "Back" to). 4. Click "Print Preview". 5. Press the "Back" button on the Intellimouse. If you think this should be filed as a seperate bug please let me know.

Piers: That's nothing to do with the mouse buttons. You get the same error if you press Alt+Left Arrow.

I would agree with Dean. Please file a separate bug on the print preview issue.

Actually Microsoft includes this functionality in Windows if you download the appropriate software from their site and it seems to work w/ Moz wo/ any xtra configuration and I think that the other OSes/3rd parties probably include the drivers to do this.

Actually Microsoft includes this functionality in Windows if you download the appropriate software from their site and it seems to work w/ Moz wo/ any xtra configuration and I think that the other OSes/3rd parties probably include the drivers to do this.

*** Bug 160506 has been marked as a duplicate of this bug. ***

*** Bug 182255 has been marked as a duplicate of this bug. ***

I have an ALPS Touch Pad on my laptop, which provides support for Back/Forward buttons through so-called gestures. (You drag to the left or right, respectively, at the very top of the Touch Pad.) Under Windows 2000 SP 2, the gestures work with Internet Explorer as well as Netscape Navigator 4.7 but not with Mozilla (I have used 1.1 beta, 1.1, and 1.2). This comment is mainly to say that this is an issue for more pointing devices than Microsoft Intellipoint. Also, the driver does not let me assign Alt+Left/Right keystrokes to the gestures, so there is no easy workaround.

re comment 149 Mouse Gesture is available through http://optimoz.mozdev.org

*** Bug 182851 has been marked as a duplicate of this bug. ***

Piers: If you filed another bug on the Print Preview issue, please provide a link to it here for all interested. Thank you.

All that's missing to get this in is a review of the additions to nsEventManager.cpp. Who's can review that, saari? There are the minor changes in comment 137 and comment 141, and I can attach a new patch if needed, but I'd love to get this in soon.

Brian, Yeah, sorry, forgot to do that. Error on back/forward in print preview -> bug 181622

*** Bug 182938 has been marked as a duplicate of this bug. ***

New patch to content. 1. Comments out SEARCH, FAVORITES, and HOME for now. 2. Adds break in the outer switch().

New patch. 1. Applies cleanly. 2. Fixed typo. 3. Commented out definitions of SEARCH, FAVORITES, and HOME and removed passing of those three messages through to DispatchAppCommandEvent().

Comment on attachment 108319 [details] [diff] [review] cvs diff -u mozilla/widget -- take 3 Carrying forward r=rods, sr=bryner

Comment on attachment 108318 [details] [diff] [review] cvs diff -u mozilla/content/events/src -- take 2 carrying forward sr=bryner and asking (begging? pleading??) for r= anyone. jag? rods? timeless?

Comment on attachment 108319 [details] [diff] [review] cvs diff -u mozilla/widget -- take 3 a=asa for checkin to 1.3a

Checked in. Many thanks to Makoto Kato for the original patch.

Given that this is an All/All bug, please either lave it open, or file a new bug for implementations for other OSes.

Oh right. I'm fine with either, although this bug became pretty Windows-only. This laid the framework in nsEventStateManager.cpp, so how about new bugs for other platforms?

mac: bug 31798 linux: bug 64485

I have tested and verified that the fix works (although I don't have permissions to actually update the bug status). Great job, Dean!

*** Bug 182849 has been marked as a duplicate of this bug. ***

The fix for this bug appears to have caused a regression for people whose back/forward mouse buttons already worked. This has been raised as bug 185676. A patch has just been created to fix this, but some of the experts from this bug might want to take a look.

verified fixed

*** Bug 64371 has been marked as a duplicate of this bug. ***

*** Bug 210615 has been marked as a duplicate of this bug. ***