844390 - JavaScript Error: NS_ERROR_FACTORY_NOT_REGISTERED in BrowserElementPromptService._init()

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Occasionally on my local builds (on an Unagi, if that matters) I see this once I unlock the phone for the first time:

E/GeckoConsole(  397): [JavaScript Error: "NS_ERROR_FACTORY_NOT_REGISTERED: Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIComponentManager.getClassObject]" {file: "resource://gre/modules/BrowserElementPromptService.jsm" line: 572}]

I think we have some kind of race condition here maybe.

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Oh, and the result is that I unlock to a screen that shows the time and an empty icon dock (i.e. no dialer, contacts, browser, messages icons).

Comment 2

[Justin Lebar (not reading bugmail)]

    // Wrap the existing @mozilla.org/prompter;1 implementation.
    var contractID = "@mozilla.org/prompter;1";
    var oldCID = Cm.contractIDToCID(contractID);
    var newCID = BrowserElementPromptFactory.prototype.classID;
    var oldFactory = Cm.getClassObject(Cc[contractID], Ci.nsIFactory);

It seems pretty bad if we're loading BrowserElementPromptService before we can get a mozilla.org/prompter;1.

Comment 3

[Justin Lebar (not reading bugmail)]

Kyle, maybe you can help me understand after what point in process startup the getClassObject call should succeed?

AFAICT, nsPrompter.js is registered in toolkit/ccomponents/prompts/src/nsPrompter.manifest, and after nsPrompter.js runs, the getClassObject call should succeed.  If that bit is right, how early would BrowserElementPromptService.jsm have to run in order for this exception to be thrown here?

We never want to fall back to the vanilla prompt service on B2G, so perhaps we should ignore this exception there.  But on desktop, this wrapping is unfortunately necessary.

Comment 4

[Justin Lebar (not reading bugmail)]

Thanks for filing this bug, Ben.  I have no idea what's going on here, but I have a fix for B2G in bug 844530.  The issue here may affect desktop as well, which is relevant for our tests, so I'd like to keep this open even if we don't have time to investigate atm.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Justin Lebar [:jlebar] from comment #3)
> Kyle, maybe you can help me understand after what point in process startup
> the getClassObject call should succeed?
> 
> AFAICT, nsPrompter.js is registered in
> toolkit/ccomponents/prompts/src/nsPrompter.manifest, and after nsPrompter.js
> runs, the getClassObject call should succeed.  If that bit is right, how
> early would BrowserElementPromptService.jsm have to run in order for this
> exception to be thrown here?
> 
> We never want to fall back to the vanilla prompt service on B2G, so perhaps
> we should ignore this exception there.  But on desktop, this wrapping is
> unfortunately necessary.

Well we call BrowserElementPromptService._init() when BrowserElementPromptService.jsm is imported.  So if that import happens before we get around to registering the prompt service we'll definitely have a problem.  Note that "registering" does not mean running its code, it means reading the manifest that defined it.  Idk what the manifests look like on b2g, but on desktop they're both included from the root chrome.manifest so the prompt service is registered when BrowserElementPromptService runs even though none of its code has been executed yet.  If you move nsPrompter.js's manifest to browser/chrome.manifest you'll see the problem reported here because those manifests aren't loaded until later.

Comment 6

[Ben Francis [:benfrancis]]

Ben, why do you think this bug lives in the browser app?

Comment 7

[Justin Lebar (not reading bugmail)]

(In reply to Ben Francis [:benfrancis] from comment #6)
> Ben, why do you think this bug lives in the browser app?

It doesn't.

Comment 8

[Justin Lebar (not reading bugmail)]

I saw a vanilla alert() today when I was running b2g mochitests on my desktop.  I wonder if this bug is the cause of some of our test failures.

Comment 9

[Justin Lebar (not reading bugmail)]

s/test failures/random test failures/

Comment 10

[BMO Automation]

Firefox OS is not being worked on