229986 - Brief Sound Played When Pressing Assigned Back Button (Back One Button Function) On Mouse

Status: UNCONFIRMED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Shannon Bodine]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208

Whenever I browse through a number of pages on any site & press the assigned
back button on my mouse a brief sound is emitted.  Currently I am using a Razer
Boomer Speed w/ latest drivers as of 01/03/04.  However,  I also had the issue
with my MX700 mouse. 

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Peter 'vt100' Schwindt]

couldn't that just be a driver problem with you mouse?

Comment 2

[Sergey Sokoloff]

Confirming the problem with my Firefox -- Mozilla/5.0 (Windows; U; Windows NT
5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1


Not only a short sound is played, I also symbols appearing in Find console:

♠ symbol (♠, Unicode ♠) for Forward mouse button

♦ symbol (must be ♦, Unicode ♦) for Back mouse button


So, I suppose, the sound is played because Find As You Type in Mozilla (xor Find
console in Firefox) cannot find these pretty rare symbols on the active webpage.
The sound is toggled with the same "match not found" event that toggles "Phrase
not found" message (rightmost in the Find console), and I saw the console
popping up with that message visible.

It's obviously not a driver problem since the original reporter encountered the
bug both with Boomer Speed and with MX700 mice. I am in turn confirming this bug
for Genius NetScroll+ Optical Mouse Drivers.

The above mentioned symbols must be a misinterpreted equivalent of Alt+Left and
Alt+Right keystrokes generated by mouse driver or something like that. These are
symbols from the very beginning of the classic ASCII codetable:

Alt+Left === Alt+Numpad4 === ASCII 4 === diamonds

Alt+Right === Alt+Numpad6 === ASCII 6 === spades

The problem seems easy to fix: neither the Find console in Firefox nor FAYT
routine in Mozilla should have ANY reaction for the codes of ASCII lower than
ASCII 32 for blank space; at the very least, no reaction for char(4) and char(6).

I hereby request blocking-aviary1.0 status for this bug, since the fix is going
to cost minor changes in the code, and the first Firefox release should IMHO be
granted full support for 5-button mice.

However I must admit that I am not going to make a patch for myself.

I feel that this bug is related to the following components: "Event Handling",
"Keyboard: Find as you Type".

I also feel that this bug is probably related to one or more of the following bugs:

Bug 250143 (Ignore unassigned mouse buttons >= 8 (GTK2 event handler))
Bug 264237 (Left Intellimouse mouse button doesn't work)
Bug 229609 (Mozilla does not correctly handle mouse buttons in Mac if set by
Logitech Control Center)
Bug 231402 (Back/forward mouse buttons don't work using Logitech SetPoint 1.04)
Bug 134583 (no way to rebind mouse buttons)
Bug 154105 (mouse button doesn't respond)

Somebody with proper rights please investigate and change bug relations and
component setting.

CCing myself.

Comment 3

[Sergey Sokoloff]

CCing [e-mail] as responsible for FAYT

Also I note that the symbols appearing in console could not be copied to
Bugzilla verbatim; either Firefox or Bugzilla replaces them with named entities
♠ and ♦.

Comment 4

[Asa Dotzler [:asa]]

not a blocker. 

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Sergey Sokoloff]

As long as I am not the first user seeing the problem, I can confirm that I
still see the bogus behaviour described in comment 2.

Reproduced in the most recent nightly of Deer Park branch: Mozilla/5.0 (Windows;
U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050927 Firefox/1.4

Comment 7

[Andrew Schultz]

==> FAYT

Comment 8

[Rui Zhou]

I tried to reproduce the bug and could not using Firefox 3.0. 

Comment 9

[Lee]

Firefox 3.0.7 on WinXP Pro SP3 on Dell Latitude D630 with Intel Core 2 Duo T7250. I am using a Logitech VX Revolution with thumb buttons programmed for Internet Back/Forward in Logitech SetPoint 4.72.40.

Three things happened about the same time this behavior started; so I do not know which, if any, of these are to blame. 
1) I upgraded to FF 3.0.7 from 3.0.6.
2) I upgraded to Logitech SetPoint 4.72.40 from 4.60.00.
3) I used Quick Find for the first time.

The behavior in Comment #2 is the exact behavior I see--the spade and diamond symbols in the Quick Find entry field. My pc beeps because the Quick Find cannot find a spade or diamond on the current page.

If I open a new tab to a page with an entry field and place the typing cursor in the entry field, hitting the mouse back button places the diamond in the entry field and hitting the mouse forward button places the spade in the entry field. Therefore, it's not limited to the Quick Find entry field. If I create a new tab, obviously the back and forward functions are not yet available, and the above behavior is easily observed and repeatable.

Comment 10

[Lee]

Addendum to my Comment #10

I just discovered the exact same behavior on a completely different box with different os and hardware.

This is a Vista Ultimate SP1 custom box with Intel Core 2 Duo E8400 and Logitech LX700 Keyboard/Mouse combo with SetPoint 4.72.40. This was a fresh install 1 week ago, so no upgrade to FF 3.0.7 and SetPoint 4.72.40. These were fresh installs at those release levels. Only FF 3.0.7 and SetPoint 4.72.40 are common between these 2 boxes.

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.