NS_ERROR_FILE_NOT_FOUND in PluginWrapper.installDate

NEW
Unassigned

Status

()

Toolkit
Add-ons Manager
P4
normal
5 years ago
2 years ago

People

(Reporter: gps, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [measurement:client])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
FHR is seeing the following exception when collecting add-on info. It looks like accessing PluginWrapper.installDate is throwing due to a missing file.

https://developer.mozilla.org/en-US/docs/Addons/Add-on_Manager/Addon doesn't say anything about this property possibly throwing. What's the API here? Whose bug is this?

Also, stack traces on errors FTW!

 [updateChannel#nightly,os#WINNT,distributionVersion#,vendor#Mozilla,locale#en-US,appBuildID#20130320031103
,version#22.0a1,distributionID#,id#{ec8030f7-c20a-464f-9b0e-13a3a9e97384},platformBuildID#20130320031103,platformVersion#22.0a1,hotfixVersion#,name#Firefox,xpcomabi#x86-msvc,_v#2

{(Provider error: org.mozilla.addons: Failed to collect: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFile.lastModifiedTime] Stack trace: resource://gre/modules/PluginProvider.jsm:376 < resource://gre/modules/HealthReport.jsm:5930 < onAllAddons()@resource://gre/modules/HealthReport.jsm:5862 < safeCall()@resource://gre/modules/AddonManager.jsm:81 < getAddonsByTypes_noMoreObjects()@resource://gre/modules/AddonManager.jsm:1777 < AOC_callNext()@resource://gre/modules/AddonManager.jsm:176 < getAddonsByTypes_concatAddons()@resource://gre/modules/AddonManager.jsm:1772 < resource://gre/modules/SocialService.jsm:770 < callProvider()@resource://gre/modules/AddonManager.jsm:107 < getAddonsByTypes_nextObject()@resource://gre/modules/AddonManager.jsm:1770 < AOC_callNext()@resource://gre/modules/AddonManager.jsm:182 < getAddonsByTypes_concatAddons()@resource://gre/modules/AddonManager.jsm:1772 < PL_getAddonsByTypes()@resource://gre/modules/PluginProvider.jsm:149 < callProvider()@resource://gre/modules/AddonManager.jsm:107 < getAddonsByTypes_nextObject()@resource://gre/modules/AddonManager.jsm:1770 < AOC_callNext()@resource://gre/modules/AddonManager.jsm:182 < getAddonsByTypes_concatAddons()@resource://gre/modules/AddonManager.jsm:1772 < LightweightThemeManager_getAddonsByTypes()@resource://gre/modules/LightweightThemeManager.jsm:386 < callProvider()@resource://gre/modules/AddonManager.jsm:107 < getAddonsByTypes_nextObject()@resource://gre/modules/AddonManager.jsm:1770 < AOC_callNext()@resource://gre/modules/AddonManager.jsm:182 < getAddonsByTypes_concatAddons()@resource://gre/modules/AddonManager.jsm:1772 < getAddonsByTypes_getVisibleAddons()@resource://gre/modules/XPIProvider.jsm:3283 < AsyncAddonListCallback_handleCompletion()@resource://gre/modules/XPIProvider.jsm -> resource://gre/modules/XPIProviderUtils.js:173 < <file:unknown>)}
(Reporter)

Comment 1

5 years ago
This accounts for roughly half of FHR's client-reported errors. While the incidence rate of errors is low (~0.001%), I'd like to address this bug just to cut down on the noise.
What versions of Firefox? This should have been fixed by bug 554780
Today's Nightly.
(Reporter)

Comment 4

5 years ago
The header says this was the Nightly built on 20130320031103 (that's this morning's).
(Reporter)

Comment 5

5 years ago
17.7% of the beta channel payloads with errors are reporting this error.
(Reporter)

Updated

5 years ago
Blocks: 846836
(In reply to Gregory Szorc [:gps] from comment #0)
> FHR is seeing the following exception when collecting add-on info. It looks
> like accessing PluginWrapper.installDate is throwing due to a missing file.
> 
> https://developer.mozilla.org/en-US/docs/Addons/Add-on_Manager/Addon doesn't
> say anything about this property possibly throwing. What's the API here?
> Whose bug is this?

It's an Add-ons Manager bug - it shouldn't ever throw. Wallpaper fix coming up with will also include better logging - since we don't know why this is happening, and it generally needs to protect against throwing anyway.
Assignee: nobody → bmcbride
Status: NEW → ASSIGNED
(Reporter)

Comment 7

5 years ago
FHR reports errors with stack traces. If you stuff an Error away where FHR can find it or surface it via whatever FHR calls, we can get it in Nightly payloads and you should be able to pin down the issue with more certainty.
Created attachment 736671 [details] [diff] [review]
Patch v1
Attachment #736671 - Flags: review?(dtownsend+bugmail)
(In reply to Gregory Szorc [:gps] from comment #7)
> FHR reports errors with stack traces. If you stuff an Error away where FHR
> can find it or surface it via whatever FHR calls, we can get it in Nightly
> payloads and you should be able to pin down the issue with more certainty.

Yea, was pondering the same... filed bug 861078.
Comment on attachment 736671 [details] [diff] [review]
Patch v1

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

::: toolkit/mozapps/extensions/test/xpcshell/test_plugin_installDate.js
@@ +65,5 @@
> +  AddonManager.getAddonsByTypes(["plugin"], function(addons) {
> +    do_check_true(addons.length > 0);
> +    for (let addon of addons) {
> +      try {
> +        addon.installDate;

Check this returns null.
Attachment #736671 - Flags: review?(dtownsend+bugmail) → review+
(Reporter)

Comment 11

5 years ago
We now have over 100,000 instances of this error.

Comment 12

2 years ago
needs prioritization
Assignee: bmcbride → nobody
Status: ASSIGNED → NEW
Priority: -- → P4
Whiteboard: [fhr] → [measurement:client]
No longer blocks: 846836, 861078
You need to log in before you can comment on or make changes to this bug.