Last Comment Bug 30431 - [Win] Intellimouse Explorer Backwards and Forwards button support.
: [Win] Intellimouse Explorer Backwards and Forwards button support.
: access, regression
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: x86 Windows XP
: P3 enhancement with 34 votes (vote)
: ---
Assigned To: Dean Tessman
: John Morrison
: Neil Deakin
: 31419 34898 54336 64008 64371 66045 68585 72981 79023 80675 84621 85658 89192 93158 103994 118754 133529 143380 151215 151232 160506 162209 164069 165828 167314 170647 173970 174478 174864 175494 176978 177550 178527 179904 182255 182849 182851 182938 210615 (view as bug list)
Depends on: 126161 22529
Blocks: 161346 64371 110749 116518 158464
  Show dependency treegraph
Reported: 2000-03-04 11:33 PST by shwag
Modified: 2011-08-05 22:30 PDT (History)
74 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch to fix (windows only) (10.32 KB, patch)
2001-03-22 01:55 PST, Joe Hewitt (gone)
no flags Details | Diff | Splinter Review
this patch works (11.00 KB, patch)
2001-03-22 03:13 PST, Joe Hewitt (gone)
no flags Details | Diff | Splinter Review
a patch in mozilla/widget (5.43 KB, patch)
2001-07-01 16:46 PDT, Makoto Kato [:m_kato]
no flags Details | Diff | Splinter Review
a patch in mozilla/content (1.82 KB, patch)
2001-07-01 16:49 PDT, Makoto Kato [:m_kato]
no flags Details | Diff | Splinter Review
cvs diff -u mozilla/content/events/src (2.99 KB, patch)
2002-02-18 01:12 PST, Dean Tessman
bryner: superreview+
Details | Diff | Splinter Review
cvs diff -u mozilla/widget (7.51 KB, patch)
2002-02-18 01:15 PST, Dean Tessman
bryner: superreview+
Details | Diff | Splinter Review
cvs diff -u mozilla/widget (7.52 KB, patch)
2002-11-19 22:33 PST, Dean Tessman
rods: review+
dean_tessman: superreview+
Details | Diff | Splinter Review
cvs diff -u mozilla/content/events/src -- take 2 (3.01 KB, patch)
2002-12-04 20:30 PST, Dean Tessman
timeless: review+
dean_tessman: superreview+
asa: approval1.3a+
Details | Diff | Splinter Review
cvs diff -u mozilla/widget -- take 3 (7.38 KB, patch)
2002-12-04 20:33 PST, Dean Tessman
dean_tessman: review+
dean_tessman: superreview+
asa: approval1.3a+
Details | Diff | Splinter Review

Description shwag 2000-03-04 11:33:30 PST
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.
Comment 1 shwag 2000-03-04 11:40:12 PST
Here is the MSDN API calls.

Here is a picture of the configuration dialog box.  Hope it helps.
Comment 2 Asa Dotzler [:asa] 2000-03-14 12:49:27 PST
*** Bug 31798 has been marked as a duplicate of this bug. ***
Comment 3 Asa Dotzler [:asa] 2000-03-24 12:26:31 PST
Reasonable RFE.  Confirming and assigning to (where all
helpwanted bugs live)  Adding helpwanted to keyword.
Comment 4 Asa Dotzler [:asa] 2000-03-27 15:08:30 PST
bryner, I know it's not mousewheel but is it something you would be willing ot
look into/tackle?
Comment 5 old account 2000-03-27 15:16:18 PST
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.
Comment 6 shwag 2000-03-29 18:19:17 PST
Bryner, I would be more then happy to work with you and report back to you with 
whatever information you need for testing.  
Comment 7 shwag 2000-03-29 18:29:12 PST
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."
Comment 8 shwag 2000-03-29 18:31:22 PST
sorry...I meant to type  *-NOT-*  required.
Comment 9 Alan 2000-04-02 17:23:01 PDT
*** Bug 31419 has been marked as a duplicate of this bug. ***
Comment 10 Alan S. Jones 2000-04-06 20:45:08 PDT
*** Bug 34898 has been marked as a duplicate of this bug. ***
Comment 11 Gervase Markham [:gerv] 2000-04-09 23:16:59 PDT
*** Bug 31419 has been marked as a duplicate of this bug. ***
Comment 12 Brian Albers 2000-04-22 12:35:35 PDT
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
Comment 13 Brian Ryner (not reading) 2000-09-17 20:47:40 PDT
Ben says this is now working.
Comment 14 Stephen Walker 2000-11-01 17:03:41 PST
*** Bug 54336 has been marked as a duplicate of this bug. ***
Comment 15 Stephen Walker 2000-11-01 17:06:21 PST
this doesn't work with the 2000110104 trunk build on win2k. reopening this bug 
& adding the regression keyword.
Comment 16 sairuh (rarely reading bugmail) 2000-12-21 13:51:08 PST
cc'ing aaron in case this interests him wrt accessibility.
Comment 17 Stephen Walker 2000-12-31 11:12:03 PST
*** Bug 64008 has been marked as a duplicate of this bug. ***
Comment 18 Dean Tessman 2001-01-04 23:35:47 PST
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:
Comment 19 Matt Schulkind 2001-01-05 23:01:09 PST
*** Bug 64485 has been marked as a duplicate of this bug. ***
Comment 20 Brian Ryner (not reading) 2001-02-02 21:27:03 PST
*** Bug 66045 has been marked as a duplicate of this bug. ***
Comment 21 Brian Ryner (not reading) 2001-02-12 10:05:56 PST
*** Bug 68585 has been marked as a duplicate of this bug. ***
Comment 22 tdanner 2001-02-12 20:02:50 PST
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.
Comment 23 Joe Hewitt (gone) 2001-03-22 01:53:39 PST
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.
Comment 24 Joe Hewitt (gone) 2001-03-22 01:55:10 PST
Created attachment 28468 [details] [diff] [review]
patch to fix (windows only)
Comment 25 Joe Hewitt (gone) 2001-03-22 01:56:33 PST
*** Bug 72981 has been marked as a duplicate of this bug. ***
Comment 26 Joe Hewitt (gone) 2001-03-22 02:12:28 PST
sorry, please ignore that last patch. It's broken.  New one in a minute.
Comment 27 Joe Hewitt (gone) 2001-03-22 03:13:02 PST
Created attachment 28470 [details] [diff] [review]
this patch works
Comment 28 Dean Tessman 2001-03-22 09:22:03 PST
Any idea if this works for free under earlier versions of Windows, such as 95 
and NT4?
Comment 29 Joe Hewitt (gone) 2001-04-03 16:52:34 PDT
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.  
Comment 30 timeless 2001-04-03 17:13:53 PDT
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.
Comment 31 R.K.Aa. 2001-05-05 07:32:44 PDT
*** Bug 79023 has been marked as a duplicate of this bug. ***
Comment 32 Harald Glatt 2001-05-06 09:28:28 PDT
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...
Comment 33 timeless 2001-05-06 20:23:50 PDT

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 
Comment 34 timeless 2001-05-14 05:13:22 PDT
*** Bug 80675 has been marked as a duplicate of this bug. ***
Comment 35 Alexey Chernyak 2001-05-17 17:24:22 PDT
buttons wfm on Win2K 2001051604
Comment 36 Jacek Piskozub 2001-05-31 12:15:57 PDT
11 dups. Marking mostfreq.
Comment 37 Dean Tessman 2001-06-08 08:23:53 PDT
*** Bug 84621 has been marked as a duplicate of this bug. ***
Comment 38 Chris Grant 2001-06-08 21:04:01 PDT
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!!!!
Comment 39 Harald Glatt 2001-06-09 03:20:44 PDT
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
Comment 40 Gilles Durys 2001-06-13 07:39:07 PDT
*** Bug 85658 has been marked as a duplicate of this bug. ***
Comment 41 Brian 'netdragon' Bober 2001-06-30 12:18:15 PDT
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?
Comment 42 R.K.Aa. 2001-06-30 20:46:08 PDT
*** Bug 88645 has been marked as a duplicate of this bug. ***
Comment 43 Artem Belevich 2001-06-30 21:12:07 PDT
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).
Comment 44 Makoto Kato [:m_kato] 2001-07-01 16:35:28 PDT
I have a patch and permission for checking in.  Please assign to me.
Comment 45 Makoto Kato [:m_kato] 2001-07-01 16:44:52 PDT
3/22 patch is not smart.  Because these patches do not contain Natural Keyborad 
Pro's Hot Key support.
Comment 46 Makoto Kato [:m_kato] 2001-07-01 16:46:05 PDT
Created attachment 40838 [details] [diff] [review]
a patch in mozilla/widget
Comment 47 Makoto Kato [:m_kato] 2001-07-01 16:49:13 PDT
Created attachment 40839 [details] [diff] [review]
a patch in mozilla/content
Comment 48 Makoto Kato [:m_kato] 2001-07-01 16:50:09 PDT
add me
Comment 49 Chris Lyon 2001-07-03 23:51:13 PDT
*** Bug 89192 has been marked as a duplicate of this bug. ***
Comment 50 Harald Glatt 2001-07-12 02:26:33 PDT
can you only make changes if you are assigned to do it?
Comment 51 Ayo 2001-07-13 08:42:13 PDT
   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.

Comment 52 Jeffrey Phillips 2001-07-13 08:55:09 PDT
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.
Comment 53 Harald Glatt 2001-07-13 09:00:57 PDT
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.
Comment 54 Jeffrey Phillips 2001-07-13 09:04:17 PDT
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"
Comment 55 Jeff Craven 2001-08-03 13:57:56 PDT
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).
Comment 56 Ashley Bischoff (blog at 2001-08-29 18:08:59 PDT
*** Bug 93158 has been marked as a duplicate of this bug. ***
Comment 57 Daniel Erat 2001-09-02 16:39:02 PDT
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.
Comment 58 Brian 'netdragon' Bober 2001-09-23 13:50:03 PDT
I can implement this for windows.
Comment 59 Stefan Furtmayr 2001-09-25 11:28:58 PDT
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).
Comment 60 Joe Hewitt (gone) 2001-09-28 17:50:26 PDT
relinquishing this one to the masses...
Comment 61 Alexander Maack 2001-10-15 02:38:51 PDT
Anything new about this "bug"? I missed this feature in the actual build. 
Comment 62 Matthias Versen [:Matti] 2001-11-14 07:43:43 PST
This works for me on win2k build 20011113.. and Intellimouse Explorer USB
Comment 63 Harald Glatt 2001-11-14 08:42:22 PST
I assume you have IntelliPoint software installed, the goal is to do it without
depending on this software...
Comment 64 Dean Tessman 2002-01-29 16:17:04 PST
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)
Comment 65 Brian 'netdragon' Bober 2002-01-29 17:34:01 PST
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).
Comment 66 Dean Tessman 2002-01-29 18:01:01 PST
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?
Comment 67 Dean Tessman 2002-01-29 18:02:33 PST
m_kato: If you could post another patch that's current against the trunk, I'll
take it for a test drive.
Comment 68 Brian 'netdragon' Bober 2002-01-29 18:28:06 PST
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.
Comment 69 Brian 'netdragon' Bober 2002-01-29 18:31:41 PST
dean: are you willing to take this bug to get it off the nobody radar?
Comment 70 Dean Tessman 2002-02-01 09:38:27 PST
brian: if you can tell me how to disable the pseudo-button support in my driver
without uninstalling it, then sure.
Comment 71 Brian 'netdragon' Bober 2002-02-02 23:39:59 PST
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?
Comment 72 Dean Tessman 2002-02-11 11:17:39 PST
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?
Comment 73 Dean Tessman 2002-02-17 14:43:23 PST
Note to self: use NS_NAVIGATE_START instead of NS_ACCESSIBLE_START.
Comment 74 Dean Tessman 2002-02-17 20:05:46 PST
Brian: Can you file what you said in comment 68 as a separate RFE?
Comment 75 Dean Tessman 2002-02-18 01:12:56 PST
Created attachment 70051 [details] [diff] [review]
cvs diff -u mozilla/content/events/src
Comment 76 Dean Tessman 2002-02-18 01:15:19 PST
Created attachment 70052 [details] [diff] [review]
cvs diff -u mozilla/widget

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.
Comment 77 Dean Tessman 2002-02-18 01:20:29 PST
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.
Comment 78 Dean Tessman 2002-02-19 20:41:05 PST
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.
Comment 79 Brian 'netdragon' Bober 2002-02-20 10:22:12 PST
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.
Comment 80 S. Grundner-Culemann 2002-03-30 04:20:03 PST
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).

Comment 81 shwag 2002-04-01 12:16:50 PST
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.
Comment 82 Artem Saveliev 2002-04-09 10:19:11 PDT
works just fine here (and always did) with Intellimouse Optical USB.
Just configure the buttons in mouse control panel to do forward and backward.
Comment 83 WD 2002-04-09 10:29:55 PDT

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..)
Comment 84 Ashley Bischoff (blog at 2002-04-09 10:31:11 PDT
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:
Comment 85 Jeffrey Phillips 2002-04-09 10:40:57 PDT
Also, to add to WD's comments -- this bug pertains to non-Windows operating systems.
Comment 86 Pat Suwalski 2002-04-11 16:10:42 PDT
Is there any chance of getting this patch in a compiled format? I don't 
compile in Windows.
Comment 87 Brian 'netdragon' Bober 2002-04-26 00:51:42 PDT
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.
Comment 88 Stefan Furtmayr 2002-04-29 16:39:24 PDT
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?
Comment 89 Vidar Haarr (not reading bugmail) 2002-05-08 04:33:18 PDT
could someone nominate this for nsbeta1 and/or mozilla1.0 ?
we should really get this for 1.0.
Comment 90 Eugene Savitsky 2002-05-08 07:50:00 PDT
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.

Comment 91 Jeffrey Phillips 2002-05-08 08:09:02 PDT

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
Comment 92 John Levon 2002-06-09 10:29:20 PDT
*** Bug 133529 has been marked as a duplicate of this bug. ***
Comment 93 Olivier Cahagne 2002-06-12 13:35:35 PDT
*** Bug 151215 has been marked as a duplicate of this bug. ***
Comment 94 Matthias Versen [:Matti] 2002-06-12 13:42:19 PDT
*** Bug 151232 has been marked as a duplicate of this bug. ***
Comment 95 Asa Dotzler [:asa] 2002-06-20 14:56:11 PDT
*** Bug 118754 has been marked as a duplicate of this bug. ***
Comment 96 Randy Santmann 2002-07-08 04:41:05 PDT
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!
Comment 97 Ashley Bischoff (blog at 2002-07-08 10:26:29 PDT
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. 
Comment 98 Dean Tessman 2002-07-24 20:14:15 PDT
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.
Comment 99 Andrew Hagen 2002-07-25 09:53:54 PDT
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?
Comment 100 Dean Tessman 2002-07-25 11:09:19 PDT
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.
Comment 101 jag (Peter Annema) 2002-07-26 16:20:39 PDT
saari: is this something we want for embedding?

bryner: what do you think of this patch?
Comment 102 Tuukka Tolvanen (sp3000) 2002-08-11 14:18:43 PDT
*** Bug 162209 has been marked as a duplicate of this bug. ***
Comment 103 WD 2002-08-22 10:46:01 PDT
*** Bug 143380 has been marked as a duplicate of this bug. ***
Comment 104 WD 2002-08-22 10:46:16 PDT
*** Bug 164069 has been marked as a duplicate of this bug. ***
Comment 105 Olav Vitters 2002-08-30 17:00:50 PDT
*** Bug 165828 has been marked as a duplicate of this bug. ***
Comment 106 Stephen Walker 2002-09-07 14:46:49 PDT
*** Bug 167314 has been marked as a duplicate of this bug. ***
Comment 107 Matthias Versen [:Matti] 2002-10-11 11:10:17 PDT
*** Bug 173970 has been marked as a duplicate of this bug. ***
Comment 108 Matthias Versen [:Matti] 2002-10-14 19:05:52 PDT
*** Bug 174478 has been marked as a duplicate of this bug. ***
Comment 109 Josh Birnbaum 2002-10-14 19:07:04 PDT
*** Bug 170647 has been marked as a duplicate of this bug. ***
Comment 110 Kitson Kelly 2002-10-16 16:52:18 PDT
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.
Comment 111 Asa Dotzler [:asa] 2002-10-18 16:49:49 PDT
*** Bug 174864 has been marked as a duplicate of this bug. ***
Comment 112 Dean Tessman 2002-10-18 18:21:51 PDT
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.
Comment 113 Jo Hermans 2002-10-19 11:34:31 PDT
*** Bug 175494 has been marked as a duplicate of this bug. ***
Comment 114 Chris Lyon 2002-10-27 07:24:56 PST
*** Bug 176978 has been marked as a duplicate of this bug. ***
Comment 115 Chris Lyon 2002-10-27 11:33:13 PST
*** Bug 177016 has been marked as a duplicate of this bug. ***
Comment 116 shwag 2002-10-29 22:44:55 PST
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!
Comment 117 Jo Hermans 2002-10-30 14:33:18 PST
*** Bug 177550 has been marked as a duplicate of this bug. ***
Comment 118 Chris Lyon 2002-11-05 14:36:43 PST
*** Bug 178527 has been marked as a duplicate of this bug. ***
Comment 119 Brian 2002-11-11 11:15:55 PST
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?
Comment 120 Dean Tessman 2002-11-11 13:30:57 PST
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."
Comment 121 Brian 2002-11-11 14:07:16 PST
So what have "the powers that be" said in the last 4 months?  
Comment 122 Brian 'netdragon' Bober 2002-11-17 00:28:59 PST
Dean: Why wouldn't it be checked into the trunk? Have you asked to get the 
code reviewed yet?
Comment 123 Torben 2002-11-17 05:12:43 PST
*** Bug 179904 has been marked as a duplicate of this bug. ***
Comment 124 Dean Tessman 2002-11-17 10:31:10 PST
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.
Comment 125 Brian 2002-11-17 12:14:38 PST
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?
Comment 127 Dean Tessman 2002-11-18 12:36:33 PST
Brian: read comment 98
Comment 128 Brian 2002-11-18 13:18:35 PST
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?
Comment 129 Dean Tessman 2002-11-18 18:01:28 PST
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.
Comment 130 Ben Liblit 2002-11-18 19:04:38 PST

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 131 Brian Ryner (not reading) 2002-11-19 16:24:36 PST
Comment on attachment 70052 [details] [diff] [review]
cvs diff -u mozilla/widget

Looks good
Comment 132 Dean Tessman 2002-11-19 21:37:43 PST
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 133 Dean Tessman 2002-11-19 22:22:58 PST
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=?
Comment 134 Dean Tessman 2002-11-19 22:33:16 PST
Created attachment 106886 [details] [diff] [review]
cvs diff -u mozilla/widget

This patch applies cleanly to the trunk.
Comment 135 Dean Tessman 2002-11-19 22:35:18 PST
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
Comment 136 Dean Tessman 2002-11-19 23:05:05 PST
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 137 rods (gone) 2002-11-20 01:35:12 PST
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
Comment 138 Brian 2002-11-20 14:04:32 PST
That's fine with me, too.

BTW- in nsEventStateManager, I think you're missing a break after you handle
Comment 139 Brian Ryner (not reading) 2002-11-20 16:28:35 PST
Comment on attachment 70051 [details] [diff] [review]
cvs diff -u mozilla/content/events/src

Oops, didn't mean to clear that.
Comment 140 Christian :Biesinger (don't email me, ping me on IRC) 2002-11-21 00:11:57 PST
when this gets checked in, please file new bugs to implement this in other
toolkits (at least mac, gtk, gtk2)
Comment 141 Dean Tessman 2002-11-21 12:29:17 PST
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.
Comment 142 piers 2002-11-22 11:39:40 PST
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.
Comment 143 Dean Tessman 2002-11-22 12:23:04 PST
Piers: That's nothing to do with the mouse buttons.  You get the same error if
you press Alt+Left Arrow.
Comment 144 Andrew Hagen 2002-11-22 12:30:55 PST
I would agree with Dean. Please file a separate bug on the print preview issue. 
Comment 145 Chris Rebert 2002-11-24 11:21:08 PST
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.
Comment 146 Chris Rebert 2002-11-24 11:23:36 PST
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.
Comment 147 Michael Lefevre 2002-11-27 04:33:30 PST
*** Bug 160506 has been marked as a duplicate of this bug. ***
Comment 148 Michael Lefevre 2002-11-27 12:16:41 PST
*** Bug 182255 has been marked as a duplicate of this bug. ***
Comment 149 Otto Giesenfeld 2002-11-28 03:04:35 PST
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.
Comment 150 Daniel Wang 2002-11-28 10:34:29 PST
re comment 149

Mouse Gesture is available through
Comment 151 Matthias Versen [:Matti] 2002-11-30 18:48:39 PST
*** Bug 182851 has been marked as a duplicate of this bug. ***
Comment 152 Brian 'netdragon' Bober 2002-11-30 22:53:07 PST
Piers: If you filed another bug on the Print Preview issue, please provide a 
link to it here for all interested. Thank you.
Comment 153 Dean Tessman 2002-12-01 00:36:55 PST
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.
Comment 154 piers 2002-12-01 06:19:53 PST
Brian, Yeah, sorry, forgot to do that.

Error on back/forward in print preview -> bug 181622

Comment 155 R.K.Aa. 2002-12-01 18:59:56 PST
*** Bug 182938 has been marked as a duplicate of this bug. ***
Comment 156 Dean Tessman 2002-12-04 20:30:49 PST
Created attachment 108318 [details] [diff] [review]
cvs diff -u mozilla/content/events/src   -- take 2

New patch to content.

1. Comments out SEARCH, FAVORITES, and HOME for now.
2. Adds break in the outer switch().
Comment 157 Dean Tessman 2002-12-04 20:33:24 PST
Created attachment 108319 [details] [diff] [review]
cvs diff -u mozilla/widget   -- take 3

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 158 Dean Tessman 2002-12-04 20:37:11 PST
Comment on attachment 108319 [details] [diff] [review]
cvs diff -u mozilla/widget   -- take 3

Carrying forward r=rods, sr=bryner
Comment 159 Dean Tessman 2002-12-04 20:39:05 PST
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 160 Asa Dotzler [:asa] 2002-12-05 09:25:34 PST
Comment on attachment 108319 [details] [diff] [review]
cvs diff -u mozilla/widget   -- take 3

a=asa for checkin to 1.3a
Comment 161 Dean Tessman 2002-12-05 19:47:16 PST
Checked in.  Many thanks to Makoto Kato for the original patch.
Comment 162 Christian :Biesinger (don't email me, ping me on IRC) 2002-12-06 01:57:22 PST
Given that this is an All/All bug, please either lave it open, or file a new bug
for implementations for other OSes.
Comment 163 Dean Tessman 2002-12-06 08:40:42 PST
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?
Comment 164 Daniel Wang 2002-12-06 09:04:07 PST
mac: bug 31798
linux: bug 64485
Comment 165 Brian 2002-12-06 10:21:23 PST
I have tested and verified that the fix works (although I don't have permissions
to actually update the bug status).

Great job, Dean!
Comment 166 Sébastien Delahaye 2002-12-08 06:17:31 PST
*** Bug 182849 has been marked as a duplicate of this bug. ***
Comment 167 Ian Nartowicz 2003-01-12 15:08:14 PST
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.
Comment 168 Matthias Versen [:Matti] 2003-01-12 15:14:33 PST
verified fixed 
Comment 169 Andrew Hagen 2003-02-19 10:46:42 PST
*** Bug 64371 has been marked as a duplicate of this bug. ***
Comment 170 Olivier Cahagne 2003-06-25 06:10:02 PDT
*** Bug 210615 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.