Closed Bug 636171 Opened 11 years ago Closed 4 years ago

onmouseup not detected properly when onmousedown generate a synchronous XHR

Categories

(Core :: DOM: Events, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: nfaugout, Unassigned)

References

(Blocks 1 open bug, )

Details

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
Version: unspecified → Trunk
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → events
Smaug, do we need to add mouseup to the list of thing we deliver once suppression ends?
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.
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.
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.
Blocks: 934422
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.
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.
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.
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.
Oh, wait, comment 4 shows the issue.
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.
(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.
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 :)
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.
(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.
(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.
Duplicate of this bug: 685971
Duplicate of this bug: 687451
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.
Duplicate of this bug: 537563
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.