636171 - onmouseup not detected properly when onmousedown generate a synchronous XHR

Status: RESOLVED INCOMPLETE

(Core :: DOM: Events, defect)

Description

[Nicolas Faugout]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13
Build Identifier: 4.0b11

The onmouseup event doesn't catch the right clic "button" attribute of the "event" object when fired after a onmousedown that makes a synchronouse AJAX call.
See the test at http://labs.lucca.fr/sandbox/right-clic.html

Reproducible: Always

Steps to Reproduce:
1. Create an HTML element with onmousedown on it that makes a synchronous AJAX call
2. On the onmouseup of that element, try to read the event.button attribute
3. It indicates the wrong value
Actual Results:  
Event object is not properly catch by the onmouseup handler

Expected Results:  
On IE and Chrome, le event object is OK. It contains the "button" attribute (or "which" attribute) and that attribute indicates the good value (1 for left clic, 2 for right clic)

I have the same problem with Firefox 3.6.2

Comment 1

[Boris Zbarsky [:bzbarsky]]

Smaug, do we need to add mouseup to the list of thing we deliver once suppression ends?

Comment 2

[Charlie]

Here is a very simplified reproduce script:

http://jsfiddle.net/cmcnulty/h9RDT/4/

click on the "test" link to see that the click event is never fired.  Basically it seems that a synchronous XHR prevents the rest of the event from taking place.

Comment 3

[Nicolas Faugout]

Thanks Charlie to report on this long lasting BUG.

I should add that if you make a long clic and trigger the mouseup after the XHR has finished, then the click event is properly trigerred.

Comment 4

[Charlie]

I have further refined the reproduce steps here:  http://jsfiddle.net/cmcnulty/h9RDT/5/ 

I removed any dependencies on jQuery (except to write out to the screen), and I've shown that both the mouseup and click events are affected, when a synchronous event is tied to the mousedown event.

Comment 5

[Rocco De Angelis]

Hi all,

Does somebody know a workaround for this bug while it is not fixed?
I have a legacy application and I can not change from sync to async XHR.

Comment 6

[Nicolas Faugout]

Hi,

The only tip I give to customers is to make a loooooong click !

If the onmouseup fires after the sync XHR has finished, then it is properly fired.

Otherwise, they can use Chrome, that handles it properly, even a short click.

Comment 7

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

Why can't you change the app to use async XHR? If you can add a workaround, you should be able
to change it to use async XHR.

Comment 8

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

And anyhow, a minimal testcase here would be useful.
The testcase from comment 2 works fine here, and the testcase from comment 0 is gone.

Comment 9

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

Oh, wait, comment 4 shows the issue.

Comment 10

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

Use of sync XHR on the main thread is btw strongly discouraged 
http://xhr.spec.whatwg.org/#sync-warning
https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html#sync-warning

It makes the user experience worse, and different browser engines have different issues with it.
Like this bug shows mouseevents can be tricky in Gecko. Key events tend to cause issues elsewhere etc.

Comment 11

[Nicolas Faugout]

(In reply to Olli Pettay [:smaug] from comment #7)
> Why can't you change the app to use async XHR? If you can add a workaround,
> you should be able
> to change it to use async XHR.

I agree with you that the best solution is to change the way the app behave and to avoid using sync XHR at all.

In our particular case, we use sync XHR to check user rights on the server side while he is starting a drag n drop on the client side, and if the server says "no dnd" then the client doesn't authorize the action.

A workaround using async XHR would be costly in term of development, a few days maybe to handle it properly.

Comment 12

[Rocco De Angelis]

Hi Olli,

we have a very complex and large web-application (GWT).
We use the same code for our JAVA as well as for the web application.
To switch from sync to async would be a very large re-factoring.

The application makes only a very fast and small call to the server so that the user experience 
is still nice. So I would prefer a workaround or a Fix in Firefox :)

Comment 13

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

You can't control whether sync XHR is fast or not. It is mostly about network latency, which
can be on bad connections really really slow.

Comment 14

[Rocco De Angelis]

(In reply to Olli Pettay [:smaug] from comment #13)
> You can't control whether sync XHR is fast or not. It is mostly about
> network latency, which
> can be on bad connections really really slow.

I agree with you that you can't control whether a sync XHR is fast or not.
But for an intranet application it should be fast in the most cases.
And yes I completely agree with you that the best solution would be to eliminate all sync XHR.
But we have really only less and very small sync XHRs that we don't have switch to async 
because the effort it is simply too big. A fix in Firefox would make our customers happy until we 
can eliminate all sync XHRs.

Comment 15

[Elbart]

(In reply to Olli Pettay [:smaug] from comment #10)
> Use of sync XHR on the main thread is btw strongly discouraged 
> http://xhr.spec.whatwg.org/#sync-warning
> https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html#sync-warning
> 
> It makes the user experience worse, and different browser engines have
> different issues with it.

I just wanted to write that the two documents are suggesting to show warnings in the developer tools and that Firefox isn't doing that, but then I tried a recent Nightly and alas, the warning has been added in bug 969671.

Though that's still no help for desktop users affected by this bug until e10s lands.

Comment 18

[Thomas Wisniewski]

This indeed is no longer be an issue in e10s mode (as per the test case in bug 685971 comment 5), so we can close this bug when non-e10s mode is gone.