1002262 - Correctly check XMLHttpRequest.responseXML for null-ness in Checker._updates

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[(no longer active)]

This is required with the patch to bug 994964 because XMLHttpRequest.responseXML
is nullable in WebIDL, contrary to XPIDL.

Comment 1

[(no longer active)]

Attachment: Correctly check XMLHttpRequest.responseXML for null-ness in Checker._updates

Comment 2

[Robert Strong (they/them - no direct email)]

Comment on attachment 8413438 [details] [diff] [review]
Correctly check XMLHttpRequest.responseXML for null-ness in Checker._updates

Looks fine giving the info in comment #0 and as long as tests pass. Thanks!

Comment 3

[(no longer active)]

(In reply to comment #2)
> Looks fine giving the info in comment #0 and as long as tests pass. Thanks!

This actually broke tests when I was running my patch for bug 994964 on try, which is how I found out about this, but the tests pass for me locally on a clean tree with this.

Waiting for Boris' feedback on the patch too...

Comment 4

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8413438 [details] [diff] [review]
Correctly check XMLHttpRequest.responseXML for null-ness in Checker._updates

I don't understand how the patch for bug 994964 has any effect at all here....  If this._request is an actual XHR object, then it's on WebIDL bindings both before and after, and responseXML might be null no matter what.

What's _actually_ going on here.  Does the tests fail for you locally if you back this patch out?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Oh, and all interface return types are always nullable in XPIDL, as far as IDL/XPConnect is concerned.

Comment 6

[(no longer active)]

Ah, I did things wrong here.  I must have been in the wrong directory or something...  Yes, this also happens without my patch, and actually applying this patch makes other tests fail, because we get past where we currently throw and hit other bugs.  I guess there is not much value in pursuing this.