Closed Bug 562003 Opened 14 years ago Closed 14 years ago

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

Categories

(Add-on SDK Graveyard :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: zbraniecki, Unassigned)

References

Details

Attachments

(2 files)

code snippet:
    var file = Cc["@mozilla.org/file/directory_service;1"]  
                         .getService(Ci.nsIProperties)  
                         .get("ProfD", Ci.nsIFile);  
----

exception:

[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.
Blocks: 549315
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?
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
Attached patch minimal testcaseSplinter Review
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?
yeah, let me try. I was planning to prepare a minimal testcase myself. will do that now.
ok, so the minimal testcase you provided actually exposes the bug, but the bug was fixed with checkin http://hg.mozilla.org/labs/jetpack-sdk/rev/05f65473bf45 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!
Status: NEW → RESOLVED
Closed: 14 years ago
Depends on: 557121
Resolution: --- → FIXED
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!
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
Attached image screenshot
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.

Attachment

General

Created:
Updated:
Size: