374499 - redundant JS error "nsIInterfaceRequestor::getInterface" logged by nsXPCWrappedJSClass::CheckForException when checking for extension updates

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Henrik Gemal]

whenever I try to check for updates in my latest nighlt builds I get:

Datasource: Update Started
 ----------
Datasource: Addon Update Started: {8f8fe09b-0bd3-4470-bc1b-8cad42b8203a}
 ----------
RDFItemUpdater:checkForUpdates sending a request to server for: https://addons.mozilla.org/update/VersionCheck.php?reqVersion=1&id={8f8fe09b-0bd3-4470-bc1b-8cad42b8203a}&version=0.13.1&maxAppVersion=2.0.0.*&status=userEnabled,incompatible&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=3.0a3pre&appOS=WINNT&appABI=x86-msvc, item = ({id:"{8f8fe09b-0bd3-4470-bc1b-8cad42b8203a}", version:"0.13.1", installLocationKey:"app-profile", minAppVersion:"0.8", maxAppVersion:"2.0.0.*", name:"Live HTTP Headers", xpiURL:"none", xpiHash:"", iconURL:"chrome://livehttpheaders/skin/img/Logo_32.png", updateRDF:"", type:2})
 ----------
Error: 'Component does not have requested interface' when calling method: [nsIInterfaceRequestor::getInterface] = NS_NOINTERFACE
 ----------
Error: 'Component does not have requested interface' when calling method: [nsIInterfaceRequestor::getInterface] = NS_NOINTERFACE
 ----------
RDFItemUpdater::onXMLLoad: cert issuer is not built-in
 ----------
Datasource: Addon Update Ended: {8f8fe09b-0bd3-4470-bc1b-8cad42b8203a}, status: 4
 ----------
Datasource: Update Ended

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070318 Minefield/3.0a3pre ID:2007031804 [cairo]

Comment 1

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

I suppose this is a regression from bug 373393? Are you sure that the extension update actually fails because of this error?

Comment 2

[Steve England [:stevee]]

"Works" (no error thrown in error console)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007031504 Minefield/3.0a3pre

"Broken" (errors thrown in error console)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007031605 Minefield/3.0a3pre

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-15+03&maxdate=2007-03-16+06&cvsroot=%2Fcvsroot

Comment 3

[Nickolay_Ponomarev]

What makes you think you're unable to check for updates _due_ to that exception? Did you try looking for an update and it was not found? As far as I can see, functionally nothing has changed, just a pointless error message is shown in the Error Console.

Here's the stack to that. nsHttpChannel asks nsXMLHttpRequest for an nsIProgressEventSink, and nsXMLHttpRequest in turn asks its mNotificationCallbacks, which is probably one of the components I tweaked in 373393. The component doesn't support that interface, so it indicates failure by throwing (it used to try indicating the failure via returnCode, but that was broken, so this is why this didn't happen before my check-in).

What I don't understand is why in the world CheckForException decides to log the error message in the Error Console (and in the native console on debug builds). It's not like JS methods can't fail legitimately.

nsConsoleService::LogMessage(message=0x059e3820)  Line 125	C++
nsXPCWrappedJSClass::CheckForException(ccx={...}, aPropertyName=0x00c96d30, anInterfaceName=0x05a42f08)  Line 960	C++
nsXPCWrappedJSClass::CallMethod(wrapper=0x05a226b8, methodIndex=0x0003, info=0x00c96d20, nativeParams=0x0012f3c0)  Line 1453	C++
nsXPCWrappedJS::CallMethod(methodIndex=0x0003, info=0x00c96d20, params=0x0012f3c0)  Line 566	C++
PrepareAndDispatch(self=0x059db8b0, methodIndex=0x00000003, args=0x0012f480, stackBytesToPop=0x0012f470)  Line 114	C++
SharedStub()  Line 142	C++
nsGetInterface::operator()(aIID={...}, aInstancePtr=0x059db8b0)  Line 52	C++
nsGetInterface::operator()(aIID={...}, aInstancePtr=0x0012f4b4)  Line 52	C++
nsCOMPtr<nsIProgressEventSink>::assign_from_helper(helper={...}, aIID={...})  Line 1304	C++
nsCOMPtr<nsIProgressEventSink>::operator=(rhs={...})  Line 781	C++
nsXMLHttpRequest::GetInterface(aIID={...}, aResult=0x059daa18)  Line 2069	C++
NS_QueryNotificationCallbacks(callbacks=0x059da00c, loadGroup=0x047f5f50, iid={...}, result=0x059daa18)  Line 1022	C++
nsHttpChannel::GetCallback<nsIProgressEventSink>(aResult={...})  Line 143	C++
nsHttpChannel::OnTransportStatus(trans=0x00000000, status=0x804b0007, progress=0x0000000000000000, progressMax=0x0000000000000000)  Line 4387	C++
nsTransportStatusEvent::Run()  Line 113	C++
nsThread::ProcessNextEvent(mayWait=0x00000001, result=0x0012f70c)  Line 483	C++
NS_ProcessNextEvent_P(thread=0x00b9acd0, mayWait=0x00000001)  Line 225	C++
nsBaseAppShell::Run()  Line 153	C++
nsAppStartup::Run()  Line 171	C++
XRE_main(argc=0x00000003, argv=0x00b98c28, aAppData=0x004037b4)  Line 2846	C++
main(argc=0x00000003, argv=0x00b98c28)  Line 61	C++

Comment 4

[Steve England [:stevee]]

The error in the error console is:

Error: 'Component does not have requested interface' when calling method: [nsIInterfaceRequestor::getInterface] = NS_NOINTERFACE

I've narrowed down the range in which the message starts to appear to:

No message:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007031603 Minefield/3.0a3pre

Error message:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007031605 Minefield/3.0a3pre

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-16+02&maxdate=2007-03-16+06&cvsroot=%2Fcvsroot

Bug 374096?

Comment 5

[Henrik Gemal]

totally forgot to write that in the addons dialog it says:

"An error occurred while trying to find updates for ..."

Comment 6

[Steve England [:stevee]]

And FWIW, even though the error console fills up with errors, if any extensions do have updates, they are still found and listed as per normal.

Comment 7

[Nickolay_Ponomarev]

Henrik: Are you sure it is not specific to a certain extension, but a problem with the extension manager?

Steve: That's likely because my check-in for bug 373393 required a clobber to take effect and the tinderbox only clobbers before the nightly build (I think, haven't checked).

Comment 8

[Henrik Gemal]

hmmm. Could someone please try this:

1) Install JSView version 1.3 from:
http://forum.softwareblaze.com/jsview/jsview1.3.xpi

2) Restart and try to check for updates for JSView

3) According to:
http://forum.softwareblaze.com/jsview/update.rdf
it should find version 1.4 but my build doesn't. I get "No updates found".

I'm I the only one what that problem? Using latest nightly build

Comment 9

[Nickolay_Ponomarev]

That update manifest is served with text/plain, so I doubt it works in any release. Does it? (Also is trunk still 1.9a2?)

Comment 10

[Henrik Gemal]

It works just fine in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070102 Minefield/3.0a2pre

Comment 11

[Henrik Gemal]

could it be the
<em:maxVersion>3.0a2</em:maxVersion>
that plays in here?

Comment 12

[Nickolay_Ponomarev]

(In reply to comment #11)
> could it be the
> <em:maxVersion>3.0a2</em:maxVersion>
> that plays in here?

Given that the trunk has been 3.0a3pre for a while, yes. But that extension's update manifest now has 3.0a3 as maxversion and the older version is 404. Plus stevee says update works.

I'm resummarizing this bug to be about the redundant error message, which I'm pretty sure is caused by my check in. If there's evidence of extension update being broken, then please file a bug with necessary update manifest and example XPI included - it's less likely a regression from my check-in.

Comment 13

[Nickolay_Ponomarev]

shaver: would appreciate your comments on this. You said there was a bug on this already, but I couldn't find it.

Comment 14

[Steve England [:stevee]]

Looks like the same kind of error is being throw when doing Help > Check for updates.. see bug 376956

Comment 16

[Wayne Mery (:wsmwk)]

bug 371863 a duplicate?

Comment 17

[Nickolay_Ponomarev]

> bug 371863 a duplicate?

No, not at all.

Comment 19

[Johnny Stenback (:jst)]

Sounds like a problem in the app update code, not a content problem.

Comment 20

[Nickolay_Ponomarev]

Please see comment 3. The JS-implemented nsIInterfaceRequestor needs to let its caller know it doesn't support a particular interface. It now does so by |throw|ing NS_NOINTERFACE (after my patch in bug 373393, without that patch it's broken and sometimes causes asserts instead).

It is perfectly fine for a JS method, especially for GI, to fail, but this error is logged to console by nsXPCWrappedJSClass::CheckForException redundantly. Someone told me on IRC that this is done to simplify debugging in cases where the failure is not expected.

shaver said he'd try to find time to comment on this bug with his ideas, but it never happened. IMO, this is totally not an update code issue.

Comment 21

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

Indeed, this is an xpconnect bug. Restoring blocking nomination, though I suspect a "redundant warning" probably isn't blocking at this stage.

Comment 22

[Johnny Stenback (:jst)]

Ok, fair enough, and sorry for not reading enough of this to understand what this was really about. Given that this is about a redundant error in xpconnect it's hardly a blocker. Minusing.

Comment 25

[Serge Gautherie (:sgautherie)]

Related to bug 287107 ? (And/or see bug 393627 ?)

Comment 26

[Nickolay_Ponomarev]

(In reply to comment #25)
> Related to bug 287107 ?

No, that bug is about Components.returnCode not working. This forces people to use |throw| to let their callers know about the error, which causes it to be logged in the console though.

> (And/or see bug 393627 ?)

That one is listed in dependencies for this bug; it's the same bug actually.

Comment 27

[Dave Townsend [:mossop]]

Fixed by bug 393627 (Yay!)

Comment 29

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007102503 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

V.Fixed, per bug 384693 comment 16.