Created attachment 538812 [details] [diff] [review]
Patch to fix
Our nsXMLHttpRequest implementation currently in some cases listens for the load event of the document being parsed. However it's unclear if this code is ever used. The comments making us wait mention that the parser could have been blocked by for example the XSLT processing code, however that code is disabled for XHR loads.
I ran this patch through try and all tests passed and the assertion didn't fire, so it seems like this patch does not affect behavior.
Oh, and this also removes the code that listens for error events fired on the parsed document which currently tries to make the XHR abort its load and fire an error event.
However this doesn't currently happen even if the document being loaded isn't well-formed XML. And it's also not the behavior that the XHR spec calls for.
Comment on attachment 538812 [details] [diff] [review]
Patch to fix
This is failing xpcshell tests. Something appears to be wrong in the error handling code.
Created attachment 538847 [details] [diff] [review]
Patch to fix v2
The problem is that we have xpcshell tests (and possibly internal code), which depends on the channel still being available when onerror fires. I.e. xhr.channel must not return null.
There's some redness, but it's looking infrastructure related, so marking FIXED for now.