addons.repository WARN Unknown type id when parsing addon: 5

RESOLVED FIXED in Firefox 36

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Ulrich.Windl, Assigned: ShellHacker, Mentored)

Tracking

31 Branch
mozilla35
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox35 disabled, firefox36 fixed, firefox37 fixed)

Details

(Whiteboard: [lang=js][good first bug])

Attachments

(2 attachments, 4 obsolete attachments)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 2014072000

Steps to reproduce:

When starting Firefox 31.0 (x86, openSUSE 12.3 version) on a text terminal, I see messages like these:
1408602693008	addons.repository	WARN	Unknown type id when parsing addon: 5
1408602693010	addons.repository	WARN	Unknown type id when parsing addon: 5
1408602693014	addons.repository	WARN	Unknown type id when parsing addon: 5
1408602693017	addons.repository	WARN	Unknown type id when parsing addon: 5
1408602693025	addons.repository	WARN	Unknown type id when parsing addon: 5
The run was the first run after upgrading Firefox, and it was during checking the add-ons for compatibility.
This is from: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/AddonRepository.jsm#1087

Are these experiments or hotfixes or something? Blair?
Component: Untriaged → Add-ons Manager
Flags: needinfo?(bmcbride)
Product: Firefox → Toolkit
Ulrich: Could you do the following for me, please?

* Open about:config, set extensions.logging.enabled to true
* Open Add-ons Manager
* Hit F12 to bring up the devtools - select the console
* Enter: AddonManagerPrivate.backgroundUpdateCheck();
* Wait a minute
* Open about:support, hit the "Show Folder" button to open your profile directory
* File extensions.log in that directory, and attach it to this bug

Thanks!
Flags: needinfo?(bmcbride) → needinfo?(Ulrich.Windl)
(In reply to Blair McBride from comment #3)
> * Enter: AddonManagerPrivate.backgroundUpdateCheck();

Sorry, I could not follow your instructions: Is the "console" I should open the Browser console (there are several consoles to open, it seems); if so, I found no place where to enter your command. Can you clarify?
(In reply to Ulrich Windl from comment #4)
> (In reply to Blair McBride from comment #3)
> > * Enter: AddonManagerPrivate.backgroundUpdateCheck();
> 
> Sorry, I could not follow your instructions: Is the "console" I should open
> the Browser console (there are several consoles to open, it seems); if so, I
> found no place where to enter your command. Can you clarify?

If you open the developer tools (ctrl-shift-k on Linux, IIRC) and open the settings page (gear icon), there's an option "Enable chrome and addon debugging". Check that, and open the browser console that you found before (ctrl-shift-j). Then you should find an input box to enter the command Blair mentioned.
I get this, and I cannot find an extensions.log afterwards:
AddonManagerPrivate.backgroundUpdateCheck();
ReferenceError: AddonManagerPrivate is not defined
Ah, extensions.log support is still broken (bug 986887, which is waiting for bug 1024525). You may be able to find the messages in the Browser Console (ctrl-shift-j or Tools / Web Developer / Browser Console) or, if you can run Firefox from the command line, the messages will also be printed out to your terminal.

The ReferenceError is because the console doesn't import the AddonManagerPrivate symbol by default. You can get it by adding one step to Blair's instructions:

...
ctrl-shift-J to get the Browser Console
Enter: Cu.import("resource://gre/modules/AddonManager.jsm");  // ** added step
Enter: AddonManagerPrivate.backgroundUpdateCheck();

You'll then see all the log messages scroll by in the console, and you can copy/paste them into a file to attach.
The suggestion in comment #7 worked, but I'm afraid there is little additional information in the log output:
--
Cu.import("resource://gre/modules/AddonManager.jsm");
BackstagePass { Promise: Getter, Cc: nsXPCComponents_Classes, Ci: nsXPCComponents_Interfaces, Cr: nsXPCComponents_Results, Cu: nsXPCComponents_Utils, PREF_BLOCKLIST_PINGCOUNTVERSION: "extensions.blocklist.pingCountVersion", PREF_DEFAULT_PROVIDERS_ENABLED: "extensions.defaultProviders.enabled", PREF_EM_UPDATE_ENABLED: "extensions.update.enabled", PREF_EM_LAST_APP_VERSION: "extensions.lastAppVersion", PREF_EM_LAST_PLATFORM_VERSION: "extensions.lastPlatformVersion", 92 weitere… }
AddonManagerPrivate.backgroundUpdateCheck();
undefined
1408976168477	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168484	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168518	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168521	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168530	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168533	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168536	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168542	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168549	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168552	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168568	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168576	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168578	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168583	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168586	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168592	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168594	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168597	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168607	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168622	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168626	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168644	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168649	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168654	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976168659	addons.repository	WARN	Unknown type id when parsing addon: 5
1408976172818	addons.update-checker	WARN	Update manifest for susefox@opensuse.org did not contain an updates property
1408976172913	addons.update-checker	WARN	Update manifest for trackerfox@bustany.org did not contain an updates property
1408976173288	addons.update-checker	WARN	Update manifest for {972ce4c6-7e08-4474-a285-3208198ce6fd} did not contain an updates property
Flags: needinfo?(Ulrich.Windl)
Looks like you don't have the preference set for detailed AddonManager logging:

* Open about:config, set extensions.logging.enabled to true
Posted file Firefox console output (obsolete) —
My fault: I had interpreted comment #7 ("You'll then see all the log messages scroll by in the console...") that the messages I see in the console are those that would be written to "extensions.log" if I had set extensions.logging.enabled to true; in fact the latter seems to increase the verbosity also.

Now that I repeated the procedure, I still don't see an extensions log in the folder I opened; I see an empty "extensions" directory, "extensions.ini", "extensions.json", and "extensions.sqlite". All of those were not updated today.

As the console provided more details as last time, I'll sent that, hoping it's what you need.
Unfortunately the attachment seems to be corrupt. Can you try capturing and attaching the text from the console again?

Due to an unfixed bug, you won't find an 'extensions.log' file.
On comment #11 about attachment 8478822 [details]: S**T, you are right (the local copy also has only binary zeros in it): I had the contents in gedit, so either gedit saved only zeros, or BtrFS ate all non-zero characters. I'll try to reproduce the log...
It turned out that BtrFS actually filled the file with all binary zeros (if interested see https://bugzilla.novell.com/show_bug.cgi?id=890976#c2). Sorry that I didn't realize earlier.
Attachment #8478822 - Attachment is obsolete: true
Looks to me like it's just a bunch of language packs, and the code here: 

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/AddonRepository.jsm#1074

should be updated for that and whatever 4 is (probably search plugin?). Irving, does that sound right?
Flags: needinfo?(irving)
(In reply to :Gijs Kruitbosch from comment #14)
> Looks to me like it's just a bunch of language packs, and the code here: 
> 
> http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/
> internal/AddonRepository.jsm#1074
> 
> should be updated for that and whatever 4 is (probably search plugin?).
> Irving, does that sound right?

Yes. I'm trying to find out whether AMO documents the numeric type IDs they send, but in the mean time the rest of the log messages show that we're still correctly processing the add-on update even though we can't interpret the type, so this isn't a serious problem.

I'll fill in some more details and make this a mentored bug once I get more info.

Ulrich, thanks for your help reporting and getting logs for this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(irving)
The types supported by addons.mozilla.org (AMO) are listed at (about) https://github.com/mozilla/olympia/blob/master/apps/constants/base.py#L127 - look for a series of definitions starting with

ADDON_ANY = 0
ADDON_EXTENSION = 1
ADDON_THEME = 2

In the code starting at http://hg.mozilla.org/mozilla-central/file/0753f7b93ab7/toolkit/mozapps/extensions/internal/AddonRepository.jsm#l1074, we need to:

a) Add a comment, with a link to the AMO github source mentioned above, saying that these definitions need to be updated whenever AMO adds a new type.

b) Define the mapping from type numbers to strings as a dictionary (JS object), and add:

4: "search"
5: "langpack"
6: "langpack-addon"
7: "plugin"
8: "api"
9: "lightweight-theme"
11: "webapp"

(though we don't expect to see most of those in this code, we might as well handle them)

c) When handling a type number we don't recognize, change the level of the log message from "logger.warn" to "logger.info", and include the contents of the 'guid' local variable in the log message.
Mentor: irving
Whiteboard: [lang=js][good first bug]
Posted patch Patch_1056490.patch (obsolete) — Splinter Review
I've given my shot at a patch for this, requesting review.
Assignee: nobody → sudheesh1995
Attachment #8485508 - Flags: review?(irving)
Comment on attachment 8485508 [details] [diff] [review]
Patch_1056490.patch

Review of attachment 8485508 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the patch; one slight change and it will be ready to land.

::: toolkit/mozapps/extensions/internal/AddonRepository.jsm
@@ +1109,3 @@
>              default:
> +              logger.info("Unknown type id when parsing addon: " + id);
> +              logger.info("GUID Id : " + guid);

Make these a single message rather than two lines; something like:

logger.info("Unknown type id " + id + " found when parsing response for GUID " + guid);
Attachment #8485508 - Flags: review?(irving) → feedback+
Posted patch Patch_1056490_v2.patch (obsolete) — Splinter Review
Outdates previous patch. Fixes logger.info into one line from two lines.
Attachment #8485508 - Attachment is obsolete: true
Attachment #8485618 - Flags: review?(irving)
Comment on attachment 8485618 [details] [diff] [review]
Patch_1056490_v2.patch

Review of attachment 8485618 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thanks for the patch. Are you interested in picking up something a bit bigger? Bug 1003204 is a straightforward change, but it needs to be made in a lot of places.
Attachment #8485618 - Flags: review?(irving) → review+
Bah, forgot to check the patch header while reviewing.

Shellhacker, please read https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F and submit a new version of the patch that has correctly formatted headers and information.
Flags: needinfo?(sudheesh1995)
Keywords: checkin-needed
I just managed to ./mach mercurial-setup and setup everything so far.
I branched out from default and created a commit of the file. Now I try

hg diff -r 203908:9fd98385062e -r 203909:74b014d32daa >> Patch_1056490_v3.patch

I still don't find the formatted headers in the patch file.
Flags: needinfo?(sudheesh1995)
Use 'hg export' rather than 'hg diff' to generate your patch file.
Flags: needinfo?(sudheesh1995)
Posted patch Patch_1056490_v3.patch (obsolete) — Splinter Review
Final fix. :)
Attachment #8485618 - Attachment is obsolete: true
Attachment #8486017 - Flags: review?(irving)
Flags: needinfo?(sudheesh1995)
Comment on attachment 8486017 [details] [diff] [review]
Patch_1056490_v3.patch

Review of attachment 8486017 [details] [diff] [review]:
-----------------------------------------------------------------

The commit message in the patch header (the first non-# line) still isn't quite what we want. I updated the documentation at https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#Commit_Message_Conventions to be more obvious, but the message needs to look like:

Bug NNNN - description of change (optional: r=reviewer)

For example,

Bug 1056490 - Add support for all type codes AMO can send; r=irving

You can fix this by just manually editing your patch file and attaching it to the bug again, you don't need to use Mercurial commands if you don't want to. With that change, this will be ready to land :-)

Please note that the meaning of "r-" (Review denied) at Mozilla isn't "your work was bad", it is "Your work isn't ready to check in yet." This case is a good example - your work is fine, I just need to teach you all the extra steps we follow at Mozilla to get things done our way.
Attachment #8486017 - Flags: review?(irving) → review-
Obsoletes older patch. Fixes the commit message.
Attachment #8486017 - Attachment is obsolete: true
Attachment #8486904 - Flags: review?(irving)
Comment on attachment 8486904 [details] [diff] [review]
Patch_1056490_v4.patch

Review of attachment 8486904 [details] [diff] [review]:
-----------------------------------------------------------------

This is good enough, we can check this version in. For future patch commit messages, you should describe the change that you made rather than describing the problem (for this bug, the example in comment 26 is the sort of thing we prefer).
Attachment #8486904 - Flags: review?(irving) → review+
Try run in comment 21 still applies; subsequent changes have been to patch metadata.
Status: NEW → ASSIGNED
Keywords: checkin-needed
https://hg.mozilla.org/integration/fx-team/rev/4b0ba1775012
Keywords: checkin-needed
Whiteboard: [lang=js][good first bug] → [lang=js][good first bug][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/4b0ba1775012
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [lang=js][good first bug][fixed-in-fx-team] → [lang=js][good first bug]
Target Milestone: --- → mozilla35
Depends on: 1093034
This was backed out from Fx35 in bug 1093034.
You need to log in before you can comment on or make changes to this bug.