As far as I see, there isn't any reason for nsIJSXMLHttpRequest. Especially after Bug 372964 things should just work like with any other event target.

Actually this could be morphed to a bug to change nsIXMLHttpRequest to be more like XHR in XHR2 spec.

We should do this.

I left it as an empty interface for compat, but if it's not used much (which should be true), we can just nuke it.

onuploadprogress was the only member of nsIJSXMLHttpRequest. Anything depending on onuploadprogress will fail anyway. If the interface has been merged to the parent (like nsIWindowInternal or nsILocalFile), leaving empty interface will make sense. But that is not the case here.

The concern is things doing createInstance with the nsIJSXMLHttpRequest IID passed in, then just doing normal XHR. Those places would start to throw. For what it's worth, at least http://hg.mozilla.org/mozilla-central/file/57499abe6479/toolkit/components/url-classifier/content/xml-fetcher.js#l28 and http://hg.mozilla.org/mozilla-central/file/57499abe6479/toolkit/mozapps/extensions/nsBlocklistService.js#l516 do exactly that in our tree. And I see 60 hits on the string "nsIJSXMLHttpRequest" in the addons mxr. All look like the same basic pattern...

Comment on attachment 8896343 [details] Bug 437381 - Remove nsIJSXMLHttpRequest and fix the comments in nsIXMLHttpRequest.h. https://reviewboard.mozilla.org/r/167604/#review172836

Pushed by VYV03354@nifty.ne.jp: https://hg.mozilla.org/integration/autoland/rev/7d262cd9d65a Remove nsIJSXMLHttpRequest and fix the comments in nsIXMLHttpRequest.h. r=smaug

I've deleted the nsIJSXMLHttpRequest page, since it is not present in Gecko anymore.