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.
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
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?
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!
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".
Created attachment 536543 [details] 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.