Closed Bug 810691 Opened 11 years ago Closed 3 years ago
Event propagation's target can be incorrect
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.
Component: Untriaged → Event Handling
Product: Firefox → Core
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.
Is this just about mouse events being blocked while sync XHR is active?
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
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.
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.
Oops... reproduce steps are here: http://jsfiddle.net/cmcnulty/h9RDT/5/
Component: Event Handling → User events and focus handling
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.