30431 - [Win] Intellimouse Explorer Backwards and Forwards button support.

Status: VERIFIED FIXED

(Core :: XUL, enhancement, P3)

Description

[shwag]

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]

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

Comment 2

[Asa Dotzler [:asa]]

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

Comment 3

[Asa Dotzler [:asa]]

Reasonable RFE.  Confirming and assigning to [e-mail] (where all
helpwanted bugs live)  Adding helpwanted to keyword.

Comment 4

[Asa Dotzler [:asa]]

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

Comment 5

[old account]

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]

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]

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]

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

Comment 9

[Alan]

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

Comment 10

[Alan S. Jones]

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

Comment 11

[Gervase Markham [:gerv]]

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

Comment 12

[Brian Albers]

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)]

Ben says this is now working.

Comment 14

[Stephen Walker]

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

Comment 15

[Stephen Walker]

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

Comment 16

[sairuh (rarely reading bugmail)]

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

Comment 17

[Stephen Walker]

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

Comment 18

[:deanis74]

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

Comment 19

[Matt Schulkind]

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

Comment 20

[Brian Ryner (not reading)]

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

Comment 21

[Brian Ryner (not reading)]

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

Comment 22

[tdanner]

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)]

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)]

Attachment: patch to fix (windows only)

Comment 25

[Joe Hewitt (gone)]

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

Comment 26

[Joe Hewitt (gone)]

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

Comment 27

[Joe Hewitt (gone)]

Attachment: this patch works

Comment 28

[:deanis74]

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

Comment 29

[Joe Hewitt (gone)]

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]

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.]

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

Comment 32

[Harald Glatt]

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]

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

Comment 34

[timeless]

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

Comment 35

[Alexey Chernyak]

buttons wfm on Win2K 2001051604

Comment 36

[Jacek Piskozub]

11 dups. Marking mostfreq.

Comment 37

[:deanis74]

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

Comment 38

[Chris Grant]

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]

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]

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

Comment 41

[Brian 'netdragon' Bober]

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.]

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

Comment 43

[Artem Belevich]

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).

Comment 44

[Makoto Kato [:m_kato]]

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

Comment 45

[Makoto Kato [:m_kato]]

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

Attachment: a patch in mozilla/widget

Comment 47

[Makoto Kato [:m_kato]]

Attachment: a patch in mozilla/content

Comment 48

[Makoto Kato [:m_kato]]

add me

Comment 49

[Chris Lyon]

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

Comment 50

[Harald Glatt]

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

Comment 51

[Ayo]

   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]

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.

Comment 53

[Harald Glatt]

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]

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]

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 handcoding.com)]

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

Comment 57

[Daniel Erat]

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]

I can implement this for windows.

Comment 59

[Stefan Furtmayr]

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)]

relinquishing this one to the masses...

Comment 61

[Alexander Maack]

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

Comment 62

[Matthias Versen [:Matti]]

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

Comment 63

[Harald Glatt]

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

Comment 64

[:deanis74]

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)

Comment 65

[Brian 'netdragon' Bober]

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).

Comment 66

[:deanis74]

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

[:deanis74]

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]

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]

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

Comment 70

[:deanis74]

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]

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

[:deanis74]

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

[:deanis74]

Note to self: use NS_NAVIGATE_START instead of NS_ACCESSIBLE_START.

Comment 74

[:deanis74]

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

Comment 75

[:deanis74]

Attachment: cvs diff -u mozilla/content/events/src

Comment 76

[:deanis74]

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

[:deanis74]

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.

Comment 78

[:deanis74]

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]

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]

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

Comment 81

[shwag]

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]

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]

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..)

Comment 84

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 85

[Jeffrey Phillips]

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

Comment 86

[Pat Suwalski]

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

Comment 87

[Brian 'netdragon' Bober]

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]

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?

Comment 89

[Vidar Haarr (not reading bugmail)]

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

Comment 90

[Eugene Savitsky]

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

Comment 91

[Jeffrey Phillips]

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.

Comment 92

[John Levon]

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

Comment 93

[Olivier Cahagne]

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

Comment 94

[Matthias Versen [:Matti]]

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

Comment 95

[Asa Dotzler [:asa]]

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

Comment 96

[Randy Santmann]

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

Comment 97

[Ashley Bischoff (blog at handcoding.com)]

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

[:deanis74]

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]

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

[:deanis74]

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)]

saari: is this something we want for embedding?

bryner: what do you think of this patch?

Comment 102

[Tuukka Tolvanen (sp3000)]

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

Comment 103

[WD]

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

Comment 104

[WD]

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

Comment 105

[Olav Vitters]

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

Comment 106

[Stephen Walker]

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

Comment 107

[Matthias Versen [:Matti]]

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

Comment 108

[Matthias Versen [:Matti]]

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

Comment 109

[Josh Birnbaum]

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

Comment 110

[Kitson Kelly]

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

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

Comment 112

[:deanis74]

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]

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

Comment 114

[Chris Lyon]

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

Comment 115

[Chris Lyon]

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

Comment 116

[shwag]

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]

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

Comment 118

[Chris Lyon]

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

Comment 119

[Brian]

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

[:deanis74]

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]

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

Comment 122

[Brian 'netdragon' Bober]

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

Comment 123

[Torben]

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

Comment 124

[:deanis74]

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]

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 126

[psydude256]

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.

Comment 127

[:deanis74]

Brian: read comment 98

Comment 128

[Brian]

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

[:deanis74]

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]

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 131

[Brian Ryner (not reading)]

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

Looks good

Comment 132

[:deanis74]

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

[:deanis74]

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

[:deanis74]

Attachment: cvs diff -u mozilla/widget

This patch applies cleanly to the trunk.

Comment 135

[:deanis74]

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 136

[:deanis74]

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 137

[rods (gone)]

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

Comment 138

[Brian]

That's fine with me, too.

BTW- in nsEventStateManager, I think you're missing a break after you handle
case NS_APPCOMMAND_STOP.  

Comment 139

[Brian Ryner (not reading)]

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)]

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

Comment 141

[:deanis74]

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]

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

[:deanis74]

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]

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

Comment 145

[Chris Rebert]

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]

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]

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

Comment 148

[Michael Lefevre]

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

Comment 149

[Otto Giesenfeld]

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]

re comment 149

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

Comment 151

[Matthias Versen [:Matti]]

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

Comment 152

[Brian 'netdragon' Bober]

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

[:deanis74]

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]

Brian, Yeah, sorry, forgot to do that.

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

Comment 155

[R.K.Aa.]

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

Comment 156

[:deanis74]

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

[:deanis74]

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

[:deanis74]

Comment on attachment 108319 [details] [diff] [review]
cvs diff -u mozilla/widget   -- take 3

Carrying forward r=rods, sr=bryner

Comment 159

[:deanis74]

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

Comment on attachment 108319 [details] [diff] [review]
cvs diff -u mozilla/widget   -- take 3

a=asa for checkin to 1.3a

Comment 161

[:deanis74]

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

Comment 162

[Christian :Biesinger (don't email me, ping me on IRC)]

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

[:deanis74]

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]

mac: bug 31798
linux: bug 64485

Comment 165

[Brian]

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]

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

Comment 167

[Ian Nartowicz]

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

verified fixed 

Comment 169

[Andrew Hagen]

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

Comment 170

[Olivier Cahagne]

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