Closed Bug 663749 Opened 13 years ago Closed 13 years ago

Remove load-event-listening code from nsXMLHttpRequest


(Core :: DOM: Core & HTML, defect)

Not set





(Reporter: sicking, Assigned: sicking)




(1 file, 1 obsolete file)

Attached patch Patch to fix (obsolete) — Splinter Review
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.
Attachment #538812 - Flags: review?(Olli.Pettay)
OS: Mac OS X → All
Hardware: x86 → All
Assignee: nobody → jonas
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.
Attachment #538812 - Flags: review?(Olli.Pettay)
Attached patch Patch to fix v2Splinter Review
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. must not return null.
Attachment #538812 - Attachment is obsolete: true
Attachment #538847 - Flags: review?(Olli.Pettay)
Attachment #538847 - Flags: review?(Olli.Pettay) → review+
Checked in

There's some redness, but it's looking infrastructure related, so marking FIXED for now.
Closed: 13 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.