Closed Bug 814576 Opened 7 years ago Closed 7 years ago
"abort" listener listening only for trusted events not executed for XHR if it's triggered synchronously by content calling abort()
I am registering a listener for "abort" event in XHR xhr.addEventListener("abort", onAbort, false); but it isn't executed in the following case: var request = new XMLHttpRequest(); request.open("POST", "issue2462.php", true); request.send(null); request.abort(); nsIEventListenerService.addListenerForAllEvents doesn't work either Related discussion: http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/1789488182daa387/98c98492cba74c63?hl=en#98c98492cba74c63 --- You need to test with this patch applied: https://bug800799.bugzilla.mozilla.org/attachment.cgi?id=683848 STR: 1) Install the attached extension (the source is here: https://github.com/firebug/manual-tests/tree/master/mozilla/noabort) 2) Open: https://getfirebug.com/tests/head/console/spy/2462/issue2462.html 3) Watch Firefox Error Console or OS system console. "readystatechnage" event is sent, but I don't see "abort" -> BUG --- Possibly related: Bug 802551 - onHTTPSpyReadyStateChange not sent for aborted XHR Bug 800799 - http-on-modify-request now called after JS that started the load is no longer on the stack Honza
What happens here is that nsXMLHttpRequest::Abort ends up calling nsXMLHttpRequest::DispatchProgressEvent which calls nsXMLHttpRequest::DispatchDOMEvent which ends up calling nsEventDispatcher::DispatchDOMEvent eventually. The event is marked trusted, so nsEventDispatcher::DispatchDOMEvent goes ahead and does this: aDOMEvent->SetTrusted(nsContentUtils::IsCallerChrome()); But "caller" in this case is the page calling abort(), so the event is marked untrusted. And the event listeners here are listening to trusted events only, so don't get this event. Olli, it's weird that we're marking this event untrusted. Should XHR be pushing a null JSContext on the stack somewhere here? Or should we have some way to keep DispatchDOMEvent from clobbering the trusted status of the event?
Component: Networking: HTTP → DOM: Events
Summary: "abort" listener not executed for XHR → "abort" listener listening only for trusted events not executed for XHR if it's triggered synchronously by content calling abort()
XHR should mark the event trusted.
DispatchDOMEvent doesn't clobber the trusted event status if the event hasn't be dispatched before and it is already trusted.
> XHR should mark the event trusted. It does. Quoting from nsXMLHttpRequest::DispatchProgressEvent: event->SetTrusted(true); > DispatchDOMEvent doesn't clobber the trusted event status Hmm. Right you are. Looks like the real issue is that the SetTrusted call happens before InitProgressEvent(), which clears the trusted flag?
Component: DOM: Events → DOM
Assignee: nobody → bzbarsky
Whiteboard: [firebug-p1] → [need review][firebug-p1]
Comment on attachment 685694 [details] [diff] [review] Make XMLHttpRequest really set its progress events as trusted. Thanks!
Attachment #685694 - Flags: review?(bugs) → review+
Whiteboard: [need review][firebug-p1] → [firebug-p1]
Target Milestone: --- → mozilla20
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Testing with Firebug and works great, thanks! Honza
Status: RESOLVED → VERIFIED
Any chance this would be ported to Fx19? Honza
Comment on attachment 685694 [details] [diff] [review] Make XMLHttpRequest really set its progress events as trusted. [Approval Request Comment] Bug caused by (feature/regressing bug #): Doesn't obviously seem to be a regression. User impact if declined: Some aspects of Firebug don't work correctly on some pages. Testing completed (on m-c, etc.): Manual and automated testing, but for Firefox and Firebug. Risk to taking this patch (and alternatives if risky): Very low risk, in both my opinion and Olli's String or UUID changes made by this patch: None.
Attachment #685694 - Flags: approval-mozilla-aurora?
Comment on attachment 685694 [details] [diff] [review] Make XMLHttpRequest really set its progress events as trusted. Low risk and landing before 18 beta 4 so we have time to backout if there are any surprises here.
Attachment #685694 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Excellent, thanks! Honza
You need to log in before you can comment on or make changes to this bug.