334497 - click processing doesn't use shift/modifier at click time, checks at processing time

Status: RESOLVED DUPLICATE of bug 145313

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

Description

[Daniel B.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1

It seems that Mozilla checks the state of modifier keys when a mouse click
is processed instead of using the state from when the mouse click occurred
(when the mouse-up or mouse-down event occurred).

In the message-list pane of the main mail window, shift-clicking to change 
the selection in the list doesn't work if the shift key isn't held down 
until the click is processed.  

Additionally, clicking and then pressing the shift key (mouse down, mouse
up, shift down) before the click is processed results in a shift-click
instead of a click.

Reproducible: Sometimes

Steps to Reproduce:
1.  Select one message in the message list.
2.  Shift-click on a second message in the list, releasing the shift key
    before Mozilla processes the click (changes the selection).  (With bug 
    327552, it should be easy to release the shift key fast enough.)
3.  Notice that Mozilla de-selects the first message and selects the second
    message, as if it got an unshifted click (instead of extending the 
    selection to the second message as if it got a shifted click).
4.  Repeat step 1.
5.  Plain-click on a second message in the list, and then press the shift 
    key before Mozilla processes the click and hold it until Mozilla
    processes the click (changes the selection).  
6.  Notice that Mozilla extends the selection to the second message, as if 
    it got a shifted click (instead of de-selecting the first message and 
    selecting the second message as it should for an unshifted click).

There seems to be a time dependency.  Try clicking on a third (well, 
"zeroeth") message shortly before step 1 (or step 4) above.




    

3.

Actual Results:  
See steps 3 and 6 above.

Expected Results:  
See steps 3 and 6 above.

Comment 1

[r0polach]

I confirm this behaviour.
This is very annoying, maybe the most annoying firefox problem for me,
becasue I use ctrl-clicks hundred-times a day...

Comment 2

[r0polach]

This bug has Product=Seamonkey,
I see the problem also in Firefox (1.5.0.3)

Comment 3

[r0polach]

I still see this in ff 2.0.0.3

Comment 4

[mr]

And it's still here in FF 2.0.0.6 as well.

I agree it's very annoying, considering how often I use ctrl-click. The ctrl-clicked links can be interpreted as clicked links and open in the same tab, but equally annoying is the other way around: after a SUCCESSFUL ctrl-click and a release of the ctrl key, the program is busy opening the page in the other tab and thinks that the ctrl is still down. Then when I try to scroll the page (with the right edge of my laptop touchpad) it is interpreted as a ctrl-scroll, which changes the text size of the page! This happens often, since the computer is always more or less busy when a page is loaded.

Actually the clicks don't seem perfectly timed either. I've experienced the shift/ctrl modifiers to end up interpreted BEFORE the actual click time as well as AFTER.

The result is that the user has to wait a bit longer (half a second or more) between pressing ctrl and clicking links, and then also keep the ctrl down after the click to make sure Firefox noticed that the modifier was down. Then avoid scrolling for a while (typically a second or so) to make sure FF knows that it's up. 

It prevents working quickly with an otherwise good program, and it should definitely be fixed since no other programs (that I use) seem to [have a reason to] behave like this.

I believe this is the same problem as described in Bug 145313 and Bug 265626!

Comment 5

[John Sullivan]

Yup, sounds like it's the same as bug 145313. I did a bunch of investigative work a while back which I posted to that bug - I believe losing the over-clever message reordering via PeekMessage, and relying on plain GetMessage will fix this.

However my machine is now sufficiently fast that I never see this any more, so can't test any fix myself.

Comment 6

[Serge Gautherie (:sgautherie)]

R.Duplicate