Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]



Add-on SDK
8 years ago
6 years ago


(Reporter: gandalf, Unassigned)


Firefox Tracking Flags

(Not tracked)



(2 attachments)



8 years ago
code snippet:
    var file = Cc[";1"]  
                         .get("ProfD", Ci.nsIFile);  


[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///Users/zbraniecki/projects/mozilla/jetpack/jetpack-sdk/packages/jetpack-core/lib/securable-module.js -> resource://testpack-jetpack-core-lib/l10n.js :: getStorageConn :: line 128"  data: no]
error: An exception occurred.


8 years ago
Blocks: 549315

Comment 1

8 years ago
Hmm, where was this being raised from? Was the code being executed as part of a unit test, or something else? Are you using the trunk of the jetpack-sdk repo?

Comment 2

8 years ago
yup, trunk jetpack-sdk from today (but I saw this bug week ago as well).

The code is inside jetpack-sdk/packages/jetpack-core/lib/l10n.js
Created attachment 443413 [details] [diff] [review]
minimal testcase

Here's a minimal testcase.  The only problem is that this seems to work for me.  So maybe this is too minimal.  gandalf: can you compare with the codebase on which you're experiencing the problem and see if you can figure out what needs to be added to this testcase to make it demonstrate the issue?

Comment 4

8 years ago
yeah, let me try. I was planning to prepare a minimal testcase myself. will do that now.

Comment 5

8 years ago
ok, so the minimal testcase you provided actually exposes the bug, but the bug was fixed with checkin on the very same day I reported this bug.

Yay for Atul :)

You may want to add this testcase to the pool, but I must say I'm not sure why and how does it fix it. To reproduce the bug, just revert to 1608894a97c5 and launch your testcase.
NS_ERROR_FAILURE is pretty vague, but perhaps the problem was that the module was being loaded too early in the application startup process, perhaps before the profile was available (and therefore before "ProfD" could be dereferenced), or perhaps before the directory service component had been registered.

It's also not clear how the fix resolved the problem, but it touched the code responsible for the loading of addon code after application startup, so perhaps it delays loading of addon code until a later point in the application startup process, by which time the necessary setup has taken place.

In any case, it's great that the problem has been fixed!
Last Resolved: 8 years ago
Depends on: 557121
Resolution: --- → FIXED

Comment 7

8 years ago
Yep, I think that Myk's prognosis is correct. And thanks for the compliment Gandalf, but I really think this was more Dietrich's doing than mine :)

Yay for Dietrich!

Comment 8

8 years ago
ouch, right, I looked at wrong checkin when I wrote my Yay ;)

Yay for Dietrich!

I still think it would be nice to add it as a test, but I'm not sure how to turn it into a test.
The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".
Component: Jetpack SDK → General
Product: Mozilla Labs → Add-on SDK
QA Contact: jetpack-sdk → general
Version: Trunk → unspecified
Created attachment 536543 [details]

Is this error related to this bug?

I've found it on:
Build id : Mozilla/5.0 (Android;Linux armv7l;rv:5.0)Gecko/20110527
Firefox/5.0 Fennec/5.0
Device: LG Optimus 2X
OS: Android 2.2
Cristian: hmm, that looks like a different, unrelated bug.
You need to log in before you can comment on or make changes to this bug.