Closed Bug 1056490 Opened 10 years ago Closed 10 years ago

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

Categories

(Toolkit :: Add-ons Manager, defect)

31 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla35
Tracking Status
firefox35 --- disabled
firefox36 --- fixed
firefox37 --- fixed

People

(Reporter: u20230201, Assigned: ShellHacker, Mentored)

References

Details

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

Attachments

(2 files, 4 obsolete files)

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.
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
Attached 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]
Attached 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+
Attached 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)
Attached 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
Keywords: checkin-needed
Whiteboard: [lang=js][good first bug] → [lang=js][good first bug][fixed-in-fx-team]
Status: ASSIGNED → RESOLVED
Closed: 10 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.

Attachment

General

Creator:
Created:
Updated:
Size: