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]

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

"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

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++

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?

totally forgot to write that in the addons dialog it says: "An error occurred while trying to find updates for ..."

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.

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).

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

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

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

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

(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.

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

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

bug 371863 a duplicate?

> bug 371863 a duplicate? No, not at all.

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

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.

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

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.

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

(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.

Fixed by bug 393627 (Yay!)

[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.