297169 - FF crashes when righthand mouse button is pressed after highlighting text with mouse

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Ocie Hudson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Crash caused by using the Compaq optical mouse to select (highlight) text to be
copied (from a web page), then pressing the righthand mouse button by mistake,
i.e., instead of pressing the lefthand mouse button to end the selection
process.  Several running applications were apparently not affected by the FF
crash.  However, FF would not run again, until I rebooted Windows XP.  There was
nothing produced by the Quality Agent, nor did Windows XP report any errors or
"events".  (This is possibly similar or related to Bug #294159)


Reproducible: Always

Steps to Reproduce:
1.Use the mouse to select text that is on a web page.
2.Press the righthand mouse button (instead of the left one) to stop selecting
the text.
3.

Actual Results:  
FF disappeared from the display monitor screen and from the Windows task bar. 
There were no error messages or dialogs displayed either by FF or by Windows. 
FF would not reload (re-execute) until I rebooted Windows XP.

Expected Results:  
Pressing the "wrong" mouse button is such a common error that, in this case,
NOTHING should have happened -- unless someone wants to code an error message
informing the user that pressing the righthand mouse button doesn't do anything
(in the context).

Nothing was reported to disclose the module in which the software crashed.  I
was running the default theme.  I have installed a lot of extensions, but none
that I suspect would cause this malfunction.  (It just looks to me as though the
coder forgot that someone could press the righthand button instead of the left
one to end text selection with the mouse.)

Comment 1

[Jorge Villalobos [:jorgev] (he/him)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Firefox/1.0.4
WFM
I tried the following:
- Started text selection holding the left button, selected some text and then
right-clicking. Result: selection held and context menu appeared.
- Clicked on the page, pressed shift and instead of left-clicking to select the
text within the range I right-clicked. Result: nothing was selected and context
menu appeared.
- Clicked on the page, pressed shift, left-clicked to select a portion of the
text and still pressing shift I right-clicked. Result: selection held and
context menu appeared.

Could you give any more details on the way you were selecting text and the URL
in which this occurs, if any?

Comment 2

[Daniel Costalis]

It seems that this is only reproducable if you have "click-lock" on which is a
feature in some third-party mouse drivers in which you can click the left mouse
button, drag, then click the left mouse button again to end the selection and
the bug is not reproducable unless using this feature

Comment 3

[Daniel Costalis]

However, with Microsofts built in click-lock, it WFM.

Comment 4

[Ocie Hudson]

UPDATE: The URL for the page from which I was copying text is:

http://www.salon.com/politics/war_room//index.html

The section that I had highlighted is titled "Think globally, fudge the facts
locally".  NOTE: if you do not have a Premium account, the Salon advertising
gremlin will probably prevent you from viewing the text until you look at an ad. 

Yesterday, I duplicated the problem once, doing exactly what I thought that I
had done the first time before reporting the event.  Given the events that
occur, it's a bit of a PITA to duplicate it voluntarily :-).  However, today, I
cannot duplicate it even on the same text on the referenced web page (nor on any
other pages, or texts such as this one).  After I press the left mouse button
and hold it down while I select the text, then release it and press the right
mouse button, the context menu appears.  That was what I was expecting to happen
yesterday, but the FF window disappeared, leaving me staring at the desktop --
twice.  There's surely some explanation for that, but _I_ don't have a clue.

I am using a Radio Shack "Compaq Optical Mouse with Glowing Wheel" (without a
desktop pad or grid) attached via a USB port.  The KYE driver has supposedly
been updated, and I downloaded and installed it a few weeks ago, only to
discover that it rendered the mouse unusable.  I don't know anything about
having the "click lock" on or off -- if it has that feature, I can't identify
it.  However, there is a configuration setting choice between "Office Mode" and
"Scroll Mouse Mode", with the latter mode selected when these events occurred. 
There is no "help" available to explain the distinction.

I think that we should just keep this open for a while, unconfirmed, until I or
someone else might find something to shed light on it.
  


  

Comment 5

[Ocie Hudson]

After further observation of the behaviour of the Compaq Optical Mouse with
Glowing Wheel, the incident(s) probably occurred because the mouse driver moved
the cursor to the upper righthand corner of the display screen, where the [X]
button is located (I've seen it do that at least twice since I reported the
incident).  So, when I pressed on the righthand mouse button to display the
context menu after highlighting text, Windows closed the application (Firefox)
instead.  That is apparently why there was no warning dialog from Windows nor
any Quality Feedback Agent run.  This is a really nasty characteristic of the
mouse, because the user (me) thinks that the cursor is in one place but the
mouse driver has actually moved it away to another.  The cursor might not be
particularly visible in either location.  It's a bit odd that I actually
duplicated the event shortly after the first time that it occurred, because the
behaviour of the mouse driver (moving the cursor) seems to depend upon the
passage of time, irrespective of any use of the mouse by the human, and
sometimes the cursor is moved to the upper lefthand corner of the window, where
an errant button push is likely to do less damage.