[Win] Intellimouse Explorer Backwards and Forwards button support.

VERIFIED FIXED

Status

()

Core
XUL
P3
enhancement
VERIFIED FIXED
18 years ago
6 years ago

People

(Reporter: shwag, Assigned: Dean Tessman)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {access, regression})

Trunk
x86
Windows XP
access, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 7 obsolete attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
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
(Reporter)

Updated

18 years ago
Severity: normal → enhancement

Comment 2

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

Comment 3

18 years ago
Reasonable RFE.  Confirming and assigning to nobody@mozilla.org (where all
helpwanted bugs live)  Adding helpwanted to keyword.
Assignee: cbegle → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted

Comment 4

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

Comment 5

18 years ago
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.
(Reporter)

Comment 6

18 years ago
Bryner, I would be more then happy to work with you and report back to you with 
whatever information you need for testing.  
(Reporter)

Comment 7

18 years ago
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."
(Reporter)

Comment 8

18 years ago
sorry...I meant to type  *-NOT-*  required.

Comment 9

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

Comment 10

18 years ago
*** Bug 34898 has been marked as a duplicate of this bug. ***
*** Bug 31419 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
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
(Reporter)

Updated

17 years ago
OS: Windows 98 → All
Ben says this is now working.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 14

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

Comment 15

17 years ago
this doesn't work with the 2000110104 trunk build on win2k. reopening this bug 
& adding the regression keyword.
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: FIXED → ---
cc'ing aaron in case this interests him wrt accessibility.
Keywords: access

Comment 17

17 years ago
*** Bug 64008 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 18

17 years ago
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

17 years ago
*** 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. ***

Comment 22

17 years ago
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

17 years ago
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
Status: REOPENED → NEW

Comment 24

17 years ago
Created attachment 28468 [details] [diff] [review]
patch to fix (windows only)

Comment 25

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

Comment 26

17 years ago
sorry, please ignore that last patch. It's broken.  New one in a minute.
Status: NEW → ASSIGNED

Comment 27

17 years ago
Created attachment 28470 [details] [diff] [review]
this patch works
(Assignee)

Comment 28

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

Comment 29

17 years ago
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

17 years ago
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

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

Comment 32

16 years ago
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

16 years ago
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...
 
Component: Browser-General → XP Toolkit/Widgets
QA Contact: asa → jrgm

Comment 34

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

Comment 35

16 years ago
buttons wfm on Win2K 2001051604

Comment 36

16 years ago
11 dups. Marking mostfreq.
Keywords: mostfreq
(Assignee)

Comment 37

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

Comment 38

16 years ago
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

16 years ago
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

16 years ago
*** 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?

Comment 42

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

Comment 43

16 years ago
It looks like "back" command works with logitech mouse in mozilla 0.9.2 and
logitech drivers v9.28b44 (available on their FTP site
ftp://ftp.logitech.com/pub/techsupport/mouse but not on the web).
I have a patch and permission for checking in.  Please assign to me.
3/22 patch is not smart.  Because these patches do not contain Natural Keyborad 
Pro's Hot Key support.
Created attachment 40838 [details] [diff] [review]
a patch in mozilla/widget
Created attachment 40839 [details] [diff] [review]
a patch in mozilla/content
add me

Comment 49

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

Comment 50

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

Comment 51

16 years ago
   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

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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. ***

Comment 57

16 years ago
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.

Comment 59

16 years ago
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

16 years ago
relinquishing this one to the masses...
Assignee: hewitt → nobody
Status: ASSIGNED → NEW

Comment 61

16 years ago
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

Comment 63

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

Updated

16 years ago
Blocks: 110749

Updated

16 years ago
Blocks: 116518
(Assignee)

Comment 64

16 years ago
m_kato: About your patch, which I only had a chance to take a quick look at...

- There's some indenting weirdness in |case WM_APPCOMMAND| in nsWindow.cpp

- The NS_NAVIGATE_COMMAND processing seems extensible enough to handle
enhancements such as adding support into mail (bug 110749).  Am I reading it
properly?

- The documentation on MSDN wasn't too clear.  What happens for all the people
that have the software installed already and it works fine for?  I assume that
the driver is basically simulating an Alt+Left Arrow keypress.  Does returning
TRUE in response WM_APPCOMMAND stop the driver from doing this? (the link that
timeless posted is broken)
New URL:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/mousinpt_6jz9.asp

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

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/keybinpt_8sbo.asp

Dean: From the above url, it seems like if we return true, the driver will know
we performed the behavior... Otherwise, for the case of navigation, it will
probably ignore it because Mozilla has focus.

Don't you think that we should also have a preference that allows us to work
independently of the windows settings and use the XBUTTON messages? This might
come in handy if people want to have it go forward and back, yet they use their
XBUTTONs for something else (such as mapped to the F11 key for gaming or something).
(Assignee)

Comment 66

16 years ago
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?
(Assignee)

Comment 67

16 years ago
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?
(Assignee)

Comment 70

16 years ago
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?
(Assignee)

Comment 72

16 years ago
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
(Assignee)

Comment 73

16 years ago
Note to self: use NS_NAVIGATE_START instead of NS_ACCESSIBLE_START.
(Assignee)

Comment 74

16 years ago
Brian: Can you file what you said in comment 68 as a separate RFE?
(Assignee)

Comment 75

16 years ago
Created attachment 70051 [details] [diff] [review]
cvs diff -u mozilla/content/events/src
Attachment #28468 - Attachment is obsolete: true
Attachment #28470 - Attachment is obsolete: true
Attachment #40839 - Attachment is obsolete: true
(Assignee)

Comment 76

16 years ago
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.
Attachment #40838 - Attachment is obsolete: true
(Assignee)

Comment 77

16 years ago
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.
Status: NEW → ASSIGNED

Updated

16 years ago
Depends on: 126161
(Assignee)

Comment 78

16 years ago
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.

Comment 80

16 years ago
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
(Reporter)

Comment 81

16 years ago
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

15 years ago
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

15 years ago
Artem, 

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

Confirming WFM 2002040903 on Win2k, using Intellimouse Optical [*] with driver
version 4.0.0.657 (you can see your driver version in Control Panel -> Mouse ->
Hardware -> Properties -> Driver).

[*] "Intellimouse Optical" doesn't refer to just any MS optical mouse, but
specifically this one: http://www.microsoft.com/hardware/mouse/io_info.asp

Comment 85

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

Comment 86

15 years ago
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.

Comment 88

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

Updated

15 years ago
Keywords: mozilla1.0, nsbeta1

Comment 90

15 years ago
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

15 years ago
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

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

Comment 93

15 years ago
*** Bug 151215 has been marked as a duplicate of this bug. ***
*** Bug 151232 has been marked as a duplicate of this bug. ***

Comment 95

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

Comment 96

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

Great product, & thanks 4 reading!
-Randy
Randy: As mentioned in comment #84, you can already get back/forward
functionality if you install the Intellimouse drivers.

Of course, this bug still exists in the hopes of getting that functionality
without requiring the specific drivers to be installed. 
(Assignee)

Comment 98

15 years ago
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

15 years ago
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?
Keywords: mozilla1.0 → mozilla1.1, mozilla1.2
(Assignee)

Comment 100

15 years ago
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

15 years ago
saari: is this something we want for embedding?

bryner: what do you think of this patch?
(Assignee)

Updated

15 years ago
Blocks: 64371
*** Bug 162209 has been marked as a duplicate of this bug. ***

Comment 103

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

Comment 104

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

Updated

15 years ago
Blocks: 161346

Comment 105

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

Comment 106

15 years ago
*** 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. ***

Comment 109

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

Comment 110

15 years ago
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

15 years ago
*** Bug 174864 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 112

15 years ago
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

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

Comment 114

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

Comment 115

15 years ago
*** Bug 177016 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 116

15 years ago
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

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

Updated

15 years ago
Blocks: 163993
Keywords: mozilla1.1

Updated

15 years ago
Keywords: mozilla1.3

Comment 118

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

Comment 119

15 years ago
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?
(Assignee)

Comment 120

15 years ago
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

15 years ago
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?

Comment 123

15 years ago
*** Bug 179904 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 124

15 years ago
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

15 years ago
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?

Updated

15 years ago
Attachment #70052 - Flags: superreview?(bryner)
Attachment #70052 - Flags: review?(rods)

Comment 126

15 years ago
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.

Updated

15 years ago
(Assignee)

Comment 127

15 years ago
Brian: read comment 98

Comment 128

15 years ago
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?
(Assignee)

Comment 129

15 years ago
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

15 years ago
Dean:

Be advised that there are other bug reports open requesting exactly the sort of
handling you had considered: bug 64371 for Windows; bug 66519 for X.

Perhaps this code should stay in.  If it is removed, perhaps the diffs should be
attached to one or both of these reports in case it needs to go back in again later.
Comment on attachment 70052 [details] [diff] [review]
cvs diff -u mozilla/widget

Looks good
Attachment #70052 - Flags: superreview?(bryner) → superreview+
(Assignee)

Comment 132

15 years ago
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
(Assignee)

Comment 133

15 years ago
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)
(Assignee)

Comment 134

15 years ago
Created attachment 106886 [details] [diff] [review]
cvs diff -u mozilla/widget

This patch applies cleanly to the trunk.
Attachment #70052 - Attachment is obsolete: true
(Assignee)

Comment 135

15 years ago
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.
Attachment #106886 - Flags: superreview+
Attachment #106886 - Flags: review?(rods)
(Assignee)

Comment 136

15 years ago
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

15 years ago
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
Attachment #106886 - Flags: review?(rods) → review+

Comment 138

15 years ago
That's fine with me, too.

BTW- in nsEventStateManager, I think you're missing a break after you handle
case NS_APPCOMMAND_STOP.  
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)
(Assignee)

Comment 141

15 years ago
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

15 years ago
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.
(Assignee)

Comment 143

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

Comment 144

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

Comment 145

15 years ago
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

15 years ago
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

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

Comment 148

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

Comment 149

15 years ago
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

15 years ago
re comment 149

Mouse Gesture is available through http://optimoz.mozdev.org
*** Bug 182851 has been marked as a duplicate of this bug. ***
Piers: If you filed another bug on the Print Preview issue, please provide a 
link to it here for all interested. Thank you.
(Assignee)

Comment 153

15 years ago
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

15 years ago
Brian, Yeah, sorry, forgot to do that.

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

Comment 155

15 years ago
*** Bug 182938 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 156

15 years ago
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().
Attachment #70051 - Attachment is obsolete: true
(Assignee)

Comment 157

15 years ago
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().
Attachment #106886 - Attachment is obsolete: true
(Assignee)

Comment 158

15 years ago
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+
(Assignee)

Comment 159

15 years ago
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)

Updated

15 years ago
Attachment #108318 - Flags: review?(jaggernaut)
Attachment #108318 - Flags: review+
Attachment #108318 - Flags: approval1.3a?

Updated

15 years ago
Attachment #108319 - Flags: approval1.3a?

Comment 160

15 years ago
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+

Updated

15 years ago
Attachment #108318 - Flags: approval1.3a? → approval1.3a+
(Assignee)

Comment 161

15 years ago
Checked in.  Many thanks to Makoto Kato for the original patch.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Attachment #70051 - Flags: review?(rods)

Updated

15 years ago
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.
(Assignee)

Comment 163

15 years ago
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

15 years ago
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.

Comment 165

15 years ago
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

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

Comment 167

15 years ago
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 
Status: RESOLVED → VERIFIED

Comment 169

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

Updated

15 years ago
Blocks: 164421

Comment 170

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

Updated

13 years ago
No longer blocks: 164421

Updated

13 years ago
Blocks: 158464

Updated

12 years ago
No longer blocks: 163993
You need to log in before you can comment on or make changes to this bug.