810691 - Event propagation's target can be incorrect

Status: RESOLVED WORKSFORME

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

Description

[Drew Waddell]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121024073032

Steps to reproduce:

The target of an event can be incorrect when a synchronous ajax request happens within the event.

 Steps to reproduce:

   - Bring up Firebug
   - Click in the first textarea, an async request is fired, no issue ever happens
   - Click in the second textarea, a sync request is fired, notice if the sync ajax request takes ~70 ms to respond the next click out of the textarea will not trigger, else there is no issue 

I have reported this to jQuery but they believe that it may just be a a Firefox bug.

jQuery Bug Report: http://bugs.jquery.com/ticket/12862
jsFiddle:  http://jsfiddle.net/dwaddell/dAj7B/




Actual results:

Since the steps are kind of odd I have created a video that shows what can happen.

Screen Capture video:  http://dl.dropbox.com/u/5126043/ScreenCapture_11-7-2012%201.38.52%20PM.wmv


Expected results:

The event.target should be correct regardless if an ajax synchrounous request happens.

Comment 1

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

Minimal testcase, please. Something which doesn't use jQuery, but just plain
DOM APIs, and which is *minimal*.



But yes, synchronous XHR cause event handling problems in all the browsers.
The problems are very implementation dependent. IIRC webkit based browsers may re-order key and
mouse events, Opera does something similar but the order is different and Gecko just
discards certain events which are happening during sync XHR.
Sync XHR is by all means bad for user experience and should be avoided.
No new features will be added to sync XHR running in the window context. New features will be
async only.

Comment 2

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

Is this just about mouse events being blocked while sync XHR is active?

Comment 3

[Drew Waddell]

Removed jQuery from the sync call: http://jsfiddle.net/dwaddell/xSBxW/14/

The mouse event isn't really blocked it's that when it is fired it doesn't have the correct target, it has the target of the active element which makes it seem like it is blocked.  The mouse position is correct however.

Thanks for your time, effort, and consideration,
Drew

Comment 4

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

Could I still ask for a *minimal* testcase please.
Something which explains what is the result you see and what is expected result.
And contains just the necessary code. Nothing less nothing more. And hopefully attached to this bug.

But yes, something odd is happening there.

Comment 5

[Charlie]

Here is a very minimal testcase.  When you click the 'test' link, you can see that the event propogation of the click event is abandoned - ie neither mouseup nor click are fired.  

It appears that the code here:

http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsXMLHttpRequest.cpp#2873

attempts to SuppressEventHandling()  - line 2887, and then later to unsuppress them:

UnsuppressEventHandlingAndFireEvents - line 2911.

Comment 6

[Charlie]

Oops... reproduce steps are here:

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

Comment 7

[Anne (:annevk)]

I cannot reproduce this. I suspect it has been fixed in the intervening years (though we still have bugs with synchronous XMLHttpRequest).