343553 - Extend extension logging for different use cases.

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, enhancement)

Description

[Fabio Serra]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

In case the EM doesn't find the extension update the log message
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#6374
say to check the RDF File. 
There is a case when the update.rdf is OK and it is downloaded but the GUID doesn't match.
eg:
install.rdf
 <em:id>[e-mail]</em:id>

update.rdf
<RDF:Description about="urn:mozilla:extension:{[e-mail]}">

The curly braces are part of the GUID.

So, a new item in the log for "No updates were found" should be useful.

Reproducible: Always

Comment 1

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

Is this the only message that should be logged? There are numerous other conditions where an extension developer can enter an incorrect id where we don't log today - some of which are in the EM code, others are in XUL, etc. I'd prefer where ever possible if these types of messages were kept out of the EM and instead included as part of an extension developer toolkit.

Comment 2

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

shaver - I'd like to see the creation of an extension developer toolkit. Can you help to make this happen?

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Some of this validation stuff I'd like to see in a tool people can use, certainly.  

I think we also need to help users get useful diagnostics somewhere they can copy and paste easily, because what happens on a dev system isn't always what happens on the user's system.  Right now, that's a very painful case.  We might be able to do that via an extension ("go install Firefox Mechanic, and then...") if we were totally sure that extension would always install well or give good diagnostics for failure, but I'd like to see us capture these errors better anyway.  (There are a number of things we could look at that might help a bunch, starting with having the EM install a custom console-service listener before it starts an install, and logging those errors off to wherever for brief posterity.)

We can't really keep these errors anywhere but the EM, because the EM at the end of the day is what determines if something installs or not, and it has the local context to say something like "GUID not recognized" rather than "uh, something in this cryptic RDF file is wrong somewhere".  Duplicating that logic in a validation extension will be pretty error-prone, I predict.

Comment 4

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

So, in this case the update rdf added curly braces for the ext@tld format. What specifically should be done in this case? Parsing / validation of the id's in the update rdf? Also, in this specific case we state
RDFItemUpdater:_parseV20UpdateInfo: No updates were found for:
{ext@tld}
If you are an Extension developer and were expecting there to be
updates, this could mean any number of things, since the RDF system
doesn't give up much in the way of information when the load fails.

Try checking that: 
 1. Your RDF File is correct - e.g. check that there is a top level
    RDF Resource with a URI urn:mozilla:extension:{GUID}, and that
    the <em:updates> listed all have matching GUIDs.

Comment 5

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

At least that's what I believe it states for that case. :P

Comment 6

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

(In reply to comment #4)
> So, in this case the update rdf added curly braces for the ext@tld format. What
> specifically should be done in this case?

 Parsing / validation of the id's in
> the update rdf? Also, in this specific case we state
> RDFItemUpdater:_parseV20UpdateInfo: No updates were found for:
> {ext@tld}

"...(update file contains information for "{{ext@tld}}")"

Though having the curly braces in the "found for" output seems like it would be a little deceptive, if I'm understanding you correctly.  If we present both "what we were looking for" and "what we found in here", the odds of the developer spotting the mistake are much higher, IMO.

> If you are an Extension developer and were expecting there to be
> updates, this could mean any number of things, since the RDF system
> doesn't give up much in the way of information when the load fails.

We have bugs on that? We should!

> Try checking that: 
>  1. Your RDF File is correct - e.g. check that there is a top level
>     RDF Resource with a URI urn:mozilla:extension:{GUID}, and that
>     the <em:updates> listed all have matching GUIDs.

I bet having the curly braces in there doesn't help either. :)

Comment 7

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

I recall seeing a "more helpful errors for rdf" bug previously but I wasn't able to find it and that log was added by Ben way back when.

I'll see what I can come up with to improve that along the lines you suggest... since an update rdf can contain multiple extensions and multiple versions of the same extensions the output when showing the two will be very noisy in the console even with the existing values are parsed out of the rdf.

For issues like this having a tool for validating an extension with an update rdf could be much more verbose and assist the extension author in debugging their extension. Is there a bug on creating an extension developer toolkit? No matter what we do with the EM it will never measure up to a toolkit that validated this type of info, etc.

Comment 8

[Fabio Serra]

(In reply to comment #6)
> > Try checking that: 
> >  1. Your RDF File is correct - e.g. check that there is a top level
> >     RDF Resource with a URI urn:mozilla:extension:{GUID}, and that
> >     the <em:updates> listed all have matching GUIDs.
> 
> I bet having the curly braces in there doesn't help either. :)

Right! This was what confused me.

Comment 9

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

*** Bug 350907 has been marked as a duplicate of this bug. ***

Comment 11

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Calling this fixed, as the new Add-ons Manager has a bunch more useful logging. Please file a new bug for any additional logging changes for the new Add-ons Manager.