Closed Bug 30431 Opened 20 years ago Closed 17 years ago

[Win] Intellimouse Explorer Backwards and Forwards button support.


(Core :: XUL, enhancement, P3)

Windows XP





(Reporter: shwag, Assigned: dean_tessman)


(Depends on 1 open bug, Blocks 1 open bug, )


(Keywords: access, regression)


(2 files, 7 obsolete files)

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.

Here is a picture of the configuration dialog box.  Hope it helps.
Severity: normal → enhancement
*** Bug 31798 has been marked as a duplicate of this bug. ***
Reasonable RFE.  Confirming and assigning to (where all
helpwanted bugs live)  Adding helpwanted to keyword.
Assignee: cbegle → nobody
Ever confirmed: true
Keywords: helpwanted
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
Depends on: 22529
OS: Windows 98 → All
Ben says this is now working.
Closed: 19 years ago
Resolution: --- → FIXED
*** 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.
Keywords: regression
Resolution: FIXED → ---
cc'ing aaron in case this interests him wrt accessibility.
Keywords: access
*** 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:
*** 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.
Assignee: nobody → hewitt
Attached patch patch to fix (windows only) (obsolete) — Splinter Review
*** 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.
Attached patch this patch works (obsolete) — Splinter Review
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...

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 
Component: Browser-General → XP Toolkit/Widgets
QA Contact: asa → jrgm
*** Bug 80675 has been marked as a duplicate of this bug. ***
buttons wfm on Win2K 2001051604
11 dups. Marking mostfreq.
Keywords: 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 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.
Attached patch a patch in mozilla/widget (obsolete) — Splinter Review
Attached patch a patch in mozilla/content (obsolete) — Splinter Review
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"

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...
Assignee: hewitt → nobody
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...
Blocks: 110749
Blocks: 116518
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

- 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:

(It really urks me when Microsoft changes their site layout and doesn't redirect)

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?
Assignee: nobody → dean_tessman
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?
Attachment #28468 - Attachment is obsolete: true
Attachment #28470 - Attachment is obsolete: true
Attachment #40839 - Attachment is obsolete: true
Attached patch cvs diff -u mozilla/widget (obsolete) — Splinter Review
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.
Attachment #40838 - Attachment is obsolete: true
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 

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.
Depends on: 126161
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.
Keywords: patch, review
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).

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.

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 (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:
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 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.
Keywords: mozilla1.0, nsbeta1
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.


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
*** 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: 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?
Blocks: 64371
*** 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. ***
Blocks: 161346
*** 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. ***
Blocks: majorbugs
Keywords: mozilla1.1
Keywords: mozilla1.3
*** 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?
Attachment #70052 - Flags: superreview?(bryner)
Attachment #70052 - Flags: review?(rods)
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.

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
Attachment #70052 - Flags: superreview?(bryner) → superreview+
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.
Attachment #70051 - Attachment is obsolete: true
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=?
Attachment #70051 - Attachment is obsolete: false
Attachment #70051 - Flags: superreview?(bryner)
Attachment #70051 - Flags: review?(rods)
Attached patch cvs diff -u mozilla/widget (obsolete) — Splinter Review
This patch applies cleanly to the trunk.
Attachment #70052 - Attachment is obsolete: true
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
Attachment #106886 - Flags: superreview+
Attachment #106886 - Flags: review?(rods)
Comment on attachment 106886 [details] [diff] [review]
cvs diff -u mozilla/widget

>+            switch (appCommand)
>+            {
>+              case APPCOMMAND_BROWSER_FORWARD:
>+              case APPCOMMAND_BROWSER_REFRESH:
>+              case APPCOMMAND_BROWSER_STOP:
>+              case APPCOMMAND_BROWSER_SEARCH:
>+              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
Attachment #106886 - Flags: review?(rods) → review+
That's fine with me, too.

BTW- in nsEventStateManager, I think you're missing a break after you handle
Attachment #70051 - Flags: superreview?(bryner)
Comment on attachment 70051 [details] [diff] [review]
cvs diff -u mozilla/content/events/src

Oops, didn't mean to clear that.
Attachment #70051 - Flags: superreview+
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
*** 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().
Attachment #70051 - Attachment is obsolete: true
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().
Attachment #106886 - Attachment is obsolete: true
Comment on attachment 108319 [details] [diff] [review]
cvs diff -u mozilla/widget   -- take 3

Carrying forward r=rods, sr=bryner
Attachment #108319 - Flags: superreview+
Attachment #108319 - Flags: review+
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?
Attachment #108318 - Attachment description: cvs diff -u mozilla/content/events/src take 2 → cvs diff -u mozilla/content/events/src -- take 2
Attachment #108318 - Flags: superreview+
Attachment #108318 - Flags: review?(jaggernaut)
Attachment #108318 - Flags: review?(jaggernaut)
Attachment #108318 - Flags: review+
Attachment #108318 - Flags: approval1.3a?
Attachment #108319 - Flags: approval1.3a?
Comment on attachment 108319 [details] [diff] [review]
cvs diff -u mozilla/widget   -- take 3

a=asa for checkin to 1.3a
Attachment #108319 - Flags: approval1.3a? → approval1.3a+
Attachment #108318 - Flags: approval1.3a? → approval1.3a+
Checked in.  Many thanks to Makoto Kato for the original patch.
Closed: 19 years ago17 years ago
Resolution: --- → FIXED
Attachment #70051 - Flags: review?(rods)
Attachment #70052 - Flags: review?(rods)
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
Keywords: helpwanted
OS: All → Windows XP
Summary: Intellimouse Explorer Backwards and Forwards button support. → [Win] Intellimouse Explorer Backwards and Forwards button support.
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. ***
Blocks: 164421
*** Bug 210615 has been marked as a duplicate of this bug. ***
No longer blocks: 164421
Blocks: 158464
No longer blocks: majorbugs
You need to log in before you can comment on or make changes to this bug.