428555 - NS_NOINTERFACE thrown when object is the right interface

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Ed Lee :Mardak]

This is bug 418243 but looking for the actual problem instead of working around this issue.

The code in question looks like:

this.mController.input != this

where mController.input throws NS_NOINTERFACE

However, checking the interface on the thing returned by nsAutoCompleteController::GetInput, it /does/ have the nsIAutoCompleteInput interface.

I thought that mInput that gets returned from GetInput is actually pointing to something dead because the problem shows up when the autocomplete input is removed. But I remember debugging through this and mInput had a reference count of 2.. ?

According to bug 418243, this is a regression.

Comment 1

[Ed Lee :Mardak]

(In reply to comment #0)
> However, checking the interface on the thing returned by
> nsAutoCompleteController::GetInput, it /does/ have the nsIAutoCompleteInput
> interface.
Just to be clear, I meant checking the interface from nsAutoCompleteController.cpp's GetInput (not from jsland).

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Bug 415498 recently landed so you may be seeing something that has existed for
a while. Are you seeing this in the JS console?

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #2)
> Bug 415498 recently landed so you may be seeing something that has existed for
> a while.

This bug was present before that patch landed. I don't think it's related.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

The problem, as far as I can tell is that until:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/xpcwrappednative.cpp&rev=1.189&mark=312#288

xpconnect is pointing to the nsXPTCStubBase that properly QIs to the desired interface (nsIAutocompleteInput). That QI makes the pointer point to the wrapped nsXULElement, which doesn't implement nsIAutocompleteInput, so the QI at:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/xpcwrappednative.cpp&rev=1.189&mark=1597#1566

fails, and we end up throwing the exception.

I suppose the first QI should be returning a wrapper that points to the XBL implementation of nsIAutocompleteInput, but that's failing for some reason because the node's been removed from the document so the XBL is no longer applied. That's not affecting the native code that holds a pointer directly to the nsXPTCStubBase though, so I'm not sure how it's supposed to deal. I suppose it could do the same and QI the object to nsISupports and back to detect a "dead" object...

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Attachment: workaround

Indeed, this works around the bug, by detecting the stale object in the getter. A simple QI to nsIAutoCompleteInput doesn't catch it.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Attachment: testcase

This is just a roundabout way of getting a C++ getter (nsAutocompleteController::GetInput, in this case) to attempt to return a node to JS that used to implement the interface via XBL, but has since been removed from its document and thus is no longer XBL-wrapped (or whatever, I'm not clear on this). The STR are explained in bug 418243 comment 0 (there's also an extension there that just packages this XUL file).

I'm not sure whether that makes this an XBL bug, or an xpconnect bug, or a just something that C++ getters need to deal with using workarounds like the above patch.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 315243 [details] [diff] [review]
testcase

(The testcase is a slightly modified version of Dan Stillman's testcase from bug 418243.)

Comment 8

[Ed Lee :Mardak]

Just a reminder for others that the testcase here and in the other bug won't really be useful testcases now that bug 418243 is fixed which avoids the problem by not using GetInput.

Comment 9

[Marcia Knous [:marcia]]

Mardak: I am getting this error on my console running today: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no].

Just wanted to see if it is the same error as this bug is about, and if so can we dupe Bug 389059 to it?

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Marcia: that exception is very generic, and a large number of bugs could trigger it. You can't really tell whether they are duplicates based only on the exception thrown. This particular instance affects no existing in-tree callers so it's pretty unlikely to have duplicates.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Marcia: the bug you were seeing is probably related to bug 459790. It looks like we've started reporting extra QueryInterface exceptions that we didn't report before, and also some that are bogus.

Comment 12

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.