Closed Bug 826445 Opened 12 years ago Closed 12 years ago

Gecko trunk (2013-01-03) results in a B2G black screen of death on Otoro

Categories

(Firefox OS Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 825840

People

(Reporter: justin.lebar+bug, Unassigned)

Details

Attachments

(1 file)

I get a black screen of death with Gecko trunk on my Otoro. I see > E/GeckoConsole( 106): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]" {file: "resource://gre/modules/Webapps.jsm" line: 2290}] in the log; perhaps that's the problem.
Here's the failing code let env = Cc["@mozilla.org/process/environment;1"] .getService(Ci.nsIEnvironment); let xdg_data_home_env = env.get("XDG_DATA_HOME"); let desktopINI; if (xdg_data_home_env != "") { // branch not taken } else { desktopINI = Services.dirsvc.get("Home", Ci.nsIFile); // <--- error desktopINI.append(".local"); desktopINI.append("share"); }
This may be the same as bug 825840
Indeed, I think it's probably the same.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
(In reply to Justin Lebar [:jlebar] from comment #0) > > E/GeckoConsole( 106): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]" {file: "resource://gre/modules/Webapps.jsm" line: 2290}] > > in the log; perhaps that's the problem. It's a symptom of the problem. We shouldn't even *get* there because DOMApplicationRegistry.allAppsLaunchable should be true [1]. We set it to true in shell.js, for reasons I can't figure out in the 'mozbrowserloadstart' event handler of the mozbrowser iframe that contains the system app [2]. Some digging revealed that the Cu.import() line for Webapps.jsm fails with NS_ERROR_FILE_NOT_FOUND. I checked that the file exists in the omni.ja and is valid JavaScript. Of course it must somehow be importable because later in logcat we see the line that Justin quoted above: an exception that's thrown *from* Webapps.jsm. NS_ERROR_FILE_NOT_FOUND is also thrown if there are circular imports between JSMs. But I couldn't find any. So, I tried simply moving the import out of the event handler to the top of the file, and voila, it works. (This also invalidates the circular import theory somewhat.) I have no idea what exactly is going on, or why the import was happening in the event handler, but I'll attach a patch for that change. [1] https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#2302 [2] https://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#415
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: