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)
Tracking
()
RESOLVED
FIXED
mozilla35
People
(Reporter: u20230201, Assigned: ShellHacker, Mentored)
References
Details
(Whiteboard: [lang=js][good first bug])
Attachments
(2 files, 4 obsolete files)
22.76 KB,
text/x-log
|
Details | |
2.51 KB,
patch
|
Irving
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•10 years ago
|
||
The run was the first run after upgrading Firefox, and it was during checking the add-ons for compatibility.
Comment 2•10 years ago
|
||
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
Comment 3•10 years ago
|
||
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)
Reporter | ||
Comment 4•10 years ago
|
||
(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?
Comment 5•10 years ago
|
||
(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.
Reporter | ||
Comment 6•10 years ago
|
||
I get this, and I cannot find an extensions.log afterwards:
AddonManagerPrivate.backgroundUpdateCheck();
ReferenceError: AddonManagerPrivate is not defined
Comment 7•10 years ago
|
||
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.
Reporter | ||
Comment 8•10 years ago
|
||
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)
Comment 9•10 years ago
|
||
Looks like you don't have the preference set for detailed AddonManager logging:
* Open about:config, set extensions.logging.enabled to true
Reporter | ||
Comment 10•10 years ago
|
||
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.
Comment 11•10 years ago
|
||
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.
Reporter | ||
Comment 12•10 years ago
|
||
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...
Reporter | ||
Comment 13•10 years ago
|
||
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
Comment 14•10 years ago
|
||
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)
Comment 15•10 years ago
|
||
(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)
Comment 16•10 years ago
|
||
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]
Assignee | ||
Comment 17•10 years ago
|
||
I've given my shot at a patch for this, requesting review.
Assignee: nobody → sudheesh1995
Attachment #8485508 -
Flags: review?(irving)
Comment 18•10 years ago
|
||
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+
Assignee | ||
Comment 19•10 years ago
|
||
Outdates previous patch. Fixes logger.info into one line from two lines.
Attachment #8485508 -
Attachment is obsolete: true
Attachment #8485618 -
Flags: review?(irving)
Comment 20•10 years ago
|
||
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+
Updated•10 years ago
|
Keywords: checkin-needed
Comment 21•10 years ago
|
||
Comment 22•10 years ago
|
||
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
Assignee | ||
Comment 23•10 years ago
|
||
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)
Comment 24•10 years ago
|
||
Use 'hg export' rather than 'hg diff' to generate your patch file.
Flags: needinfo?(sudheesh1995)
Assignee | ||
Comment 25•10 years ago
|
||
Final fix. :)
Attachment #8485618 -
Attachment is obsolete: true
Attachment #8486017 -
Flags: review?(irving)
Flags: needinfo?(sudheesh1995)
Comment 26•10 years ago
|
||
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-
Assignee | ||
Comment 27•10 years ago
|
||
Obsoletes older patch. Fixes the commit message.
Attachment #8486017 -
Attachment is obsolete: true
Attachment #8486904 -
Flags: review?(irving)
Comment 28•10 years ago
|
||
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+
Comment 29•10 years ago
|
||
Try run in comment 21 still applies; subsequent changes have been to patch metadata.
Status: NEW → ASSIGNED
Keywords: checkin-needed
Comment 30•10 years ago
|
||
Keywords: checkin-needed
Whiteboard: [lang=js][good first bug] → [lang=js][good first bug][fixed-in-fx-team]
Comment 31•10 years ago
|
||
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
Comment 32•10 years ago
|
||
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.
Description
•