1125570 - nsIPrefService type error: getChildList|getPrefType are not functions

Status: RESOLVED DUPLICATE of bug 1083561

(Core :: XPConnect, defect)

Description

[Toady]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:35.0) Gecko/20100101 Firefox/35.0 Cyberfox/35.0
Build ID: 20150113101917

Steps to reproduce:

let prefService = Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService);
let preflist = prefService.getChildList("extensions.myawesomeaddon.");

Returns TypeError: prefService.getChildList is not a function


let prefService = Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService);
let prefType = prefService.getPrefType("extensions.myawesomeaddon.booleanpreference");

Returns prefService.getPrefType is not a function




Actual results:

The use of getChildList and getPrefType in the latest nightly BuildID=20150124030202 no longer allows the use of these functions.

latest nightly BuildID=20150124030202

Works in 35.0.*, 36.0.*, 37.0.* but fails in 38.0.*


Expected results:

getChildList should have returned a list.
getPrefType should have returned the preference type as integer.

Is there a new way to access these functions for e10s nightly, Has something changed i haven't been able to locate any information about a change on these functions.

I hope its something simple i have overlooked in the way its called for Firefox 38.0a1 if its requires a different way to call it in multi-process enabled browser where can i find the documentation.

Comment 1

[:Gijs (he/him)]

Both of these wfm when put in the browser console on latest nightly... can you be more specific about where you're trying to use them? Are you in a frame script or something else that runs in the content process?

Comment 2

[Toady]

Attachment: TestCase_Bug1125570.xpi

Here is a test case.

If you install this into any browser version before 38.0 the results of getChildList and getPrefType return there correct values.

"extensions.testingpreferences.charpref" overlay.js:11:3
"extensions.testingpreferences.intpref" overlay.js:11:3
"extensions.testingpreferences.boolpref" overlay.js:11:3
128 overlay.js:18:0
64 overlay.js:19:0
32 overlay.js:20:2

In the latest nightly 38.0 
these functions no longer return there correct value but throw an error.
TypeError: prefService.getChildList is not a function overlay.js:7:17
TypeError: prefService.getPrefType is not a function overlay.js:18:14

With e10s enabled or disabled.

latest nightly BuildID=20150125030202

The above test is an overlay extension it will add to menu entry's to the browsers right click context menu so you can easily test each function individually.

Comment 3

[Toady]

Attachment: TestCase2_Bug1125570.xpi

In test case 2 calling the var prefService = Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService); 

Outside of the function for getChildList and getPrefType works however in test 1 calling these inside the function throws an error.

Comment 4

[:Gijs (he/him)]

I can reproduce this... if I attach the debugger, and set a breakpoint, the code starts working. Seems like a JS engine bug to me. :-\

Comment 5

[:Gijs (he/him)]

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1e2993c99323&tochange=1735ff2bb23e

Comment 6

[:Gijs (he/him)]

Toady: So the issue here is that you're using methods defined on nsIPrefBranch, but you're asking for nsIPrefService. If you add a QI to nsIPrefBranch, this will be fixed. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1030420#c15

Seems like the add-on should be fixed by doing:

prefService.QueryInterface(Components.interfaces.nsIPrefBranch);

before trying to use those methods.

This used to work because someone else would have used the pref service object before you (and asked it for nsIPrefBranch things). In nightly, your add-on code runs separately from the rest of the code in the window, and so this no longer works.

In fact, the simplest workaround will probably just be relying on Services.prefs instead.


That said, it's confusing that using the debugger changes the outcomes here, and that there wasn't really documentation / or an announcement about this change.

Bill, am I understanding this right? Anything we can do here on the platform front to make this easier?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> That said, it's confusing that using the debugger changes the outcomes here

Does the debugger use the prefservice?

> Anything we can do here on the platform front to make this easier?

Make prefservice inherit from prefbranch, no?

Comment 8

[:Gijs (he/him)]

(In reply to Boris Zbarsky [:bz] from comment #7)
> > That said, it's confusing that using the debugger changes the outcomes here
> 
> Does the debugger use the prefservice?

In the add-on compartment? That would surprise me... but it might be the best explanation, I guess. :-\

Eddy?

> 
> > Anything we can do here on the platform front to make this easier?
> 
> Make prefservice inherit from prefbranch, no?

Excuse me while 10 years worth of paradigm shift happens inside my head. (yes, I realize it's probably more for you) ;-)

Err, yeah... I guess? Any reason we can't do that?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Any reason we can't do that?

Not that obviously comes to mind, but we should check with the XPCOM module owners...

Comment 11

[Eddy Bruel [:ejpbruel]]

(In reply to :Gijs Kruitbosch from comment #8)
> (In reply to Boris Zbarsky [:bz] from comment #7)
> > > That said, it's confusing that using the debugger changes the outcomes here
> > 
> > Does the debugger use the prefservice?
> 
> In the add-on compartment? That would surprise me... but it might be the
> best explanation, I guess. :-\
> 
> Eddy?
> 

There are some places in the debugger server that use the pref service via Services.jsm (see preference.js, webapps.js, and webconsole.js, and perhaps others)