366544 - Mousedown alert still triggers click event afterwards

Status: RESOLVED FIXED

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

Description

[Martijn Wargers (dead)]

Attachment: testcase

This came from: http://forums.mozillazine.org/viewtopic.php?t=506681&highlight=

See testcase, you should only get a mousedown alert, but also a click alert is called in Mozilla. That should not happen.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Windows only?

Comment 2

[Gérard Talbot]

 http://forums.mozillazine.org/viewtopic.php?t=506681&highlight=

I do not see why this is a bug. The first alert that pops up is caused by handleMouseDown function. If you only press the left button and maintained it pressed, you'll only see the correspondent alert. Once you release the left button, then the handleClick function is carried on and its correspondent alert covers perfectly the first one generated by the mousedown event.

I tried attachment 251062 [details] with Seamonkey 1.5a rv:1.9a3pre build 2007020709 under XP Pro SP2 here.

As mentioned correctly by 2 posters (steinola and saikrishna) in

http://forums.mozillazine.org/viewtopic.php?t=506681&highlight=

"OnMouseDown is fired when the page receives the event that the mouse button has been depressed.
OnMouseUp is fired when the page receives the event that the mouse button has been released.
OnClick wraps both of these events up into a single event"

> See testcase, you should only get a mousedown alert, but also a click alert is
> called in Mozilla. That should not happen.

In my opinion, this bug should be resolved as INVALID

Comment 3

[Ere Maijala (slow)]

If the page loses focus while mouse button is depressed, it shouldn't receive the click event because the mouse wasn't really clicked in it. This is especially true in the case of a modal dialog as you cannot (or should not be able to) click the window area while the dialog is being displayed.

Comment 4

[Gérard Talbot]

> in the case of a modal dialog as you cannot (or should not be
> able to) click the window area while the dialog is being displayed.

You are referring to a situation which is not addressed by Martijn's testcase. I must point out here that modal window are now requiring enhanced security privileges from the user (see bug 180048).
Ere, can you create a testcase or provide an url demonstrating/reproducing the issue?

Attachment 251062 [details] does not demonstrate a bug; steinola (Jan 11th 2007) comment and Krishna's (saikrishna) Dec. 9th 2005 comment in the mozillazine thread both support the same reasoning and understanding of mousedown versus click events fire (and their order).

Comment 5

[Martijn Wargers (dead)]

(In reply to comment #4)
> Ere, can you create a testcase or provide an url demonstrating/reproducing the
> issue?

The alert is the modal dialog/window.

Comment 6

[Ere Maijala (slow)]

Attachment: Possible patch

When a modal dialog is displayed, the parent window is disabled and thus unable to receive mouse input. But in this case input is received by the disabled parent until the current input sequence is "complete", i.e. the button is released. This makes sense as otherwise the app could still see the button as depressed and do something stupid, such as initiate drag, when the window is again enabled. So, we need to check that the window is enabled before synthesizing a click event in nsEventStateManager. This patch adds such test. Roc, what do think?

Another possibility would be to avoid dispatching the button up event in the widget code, but then there should be a way to reset the state upon WM_ENABLE or WM_CANCELMODE.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Because this doesn't happen in Linux, I guess gtk2-widget code somehow 
prevents dispatching button_up in this case. Shouldn't Windows widget
do the same.

Comment 8

[Ere Maijala (slow)]

Attachment: Possible patch (complete)

Oops, the previous patch was missing a vital addition in nsWindow.cpp. The check for parent's state is necessary as the child window isn't disabled until the input sequence is complete.

Comment 9

[Ere Maijala (slow)]

(In reply to comment #7)
> Because this doesn't happen in Linux, I guess gtk2-widget code somehow 
> prevents dispatching button_up in this case. Shouldn't Windows widget
> do the same.
> 

How does gtk2 widget code reset the button state in higher levels? 

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #9)
> How does gtk2 widget code reset the button state in higher levels? 
> 
Which state do you mean?

Added a printf to
nsEventStateManager::PostHandleEvent ... case NS_MOUSE_BUTTON_UP:
and that never gets called in gtk2 build if alert is created onmousedown.

Comment 11

[Ere Maijala (slow)]

I mean the button state. If I suppress button up event in Win32 widget code the button "stays down" (for example text selection in the test case happens without pressing the button after the dialog is dismissed). So if this doesn't happen in gtk2 build it must be doing something to reset the state.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The code is fine, but I'm not 100% sure we should be doing this. What do other browsers do?

Comment 13

[Ere Maijala (slow)]

IE 7 and Opera 9.10 on Windows fire only mousedown. Firefox gtk2 build usually fires only mousedown but I somehow got it to fire click too once (couldn't reproduce). Konqueror only fires mousedown, but the button's logical state remains incorrectly down after dismissing the dialog. 

Comment 14

[Ere Maijala (slow)]

Also IE 6 fires only mousedown.

Comment 15

[Ere Maijala (slow)]

I accidentally checked in the nsWindow.cpp part already yesterday. Now it's all checked in to trunk.