Quickly had a look here, the issue is with https://hg.mozilla.org/mozilla-central/file/tip/devtools/client/netmonitor/src/reducers/ui.js#l56 > browserCacheDisabled: Services.prefs.getBoolPref("devtools.cache.disabled"), The pref is not defined when starting netmonitor in Launchpad and makes the netmonitor fail. I recently updated the Services shim used in Launchpad in order to support optional default arguments, so when we switch to the next release of devtools-modules (v0.0.29, trying to create a release at the moment), we can use: > getBoolPref("devtools.cache.disabled", false) which will avoid the crash. Maybe there is a way to initialize prefs for Launchpad, but I don't believe I have seen anything like that so far.

(In reply to Julian Descottes [:jdescottes] from comment #1) > which will avoid the crash. Maybe there is a way to initialize prefs for > Launchpad, but I don't believe I have seen anything like that so far. There's https://dxr.mozilla.org/mozilla-central/source/devtools/client/netmonitor/index.js but apparently that's not enough according to Ruturaj (see https://bugzilla.mozilla.org/show_bug.cgi?id=1364096#c45) I think it would be nice if we could get rid of index.js altogether and only use the optional default arguments, so we don't have to initialize prefs twice (once in index.js and once in devtools/client/preferences).

I didn't know we were initializing prefs there! That's interesting. So the issue with index.js is that is initializes prefs a bit too late. If you move the prefs initialization before > const { configureStore } = require("./src/utils/create-store"); And add > pref("devtools.cache.disabled", false); Then it works. > I think it would be nice if we could get rid of index.js altogether and only use > the optional default arguments, so we don't have to initialize prefs twice (once > in index.js and once in devtools/client/preferences). I agree it's not ideal, to have to duplicate a default value like that. In theory I would prefer loading the devtools.js preferences file in launchpad, rather than having to define fallback values whenever we get the preferences. For this bug here, I guess the best short term is to update index.js in order to add the pref.

(In reply to Julian Descottes [:jdescottes] from comment #4) > I didn't know we were initializing prefs there! That's interesting. > > So the issue with index.js is that is initializes prefs a bit too late. If > you move the prefs initialization before > > > const { configureStore } = require("./src/utils/create-store"); > > And add > > > pref("devtools.cache.disabled", false); > > Then it works. Ah, good catch! > > I think it would be nice if we could get rid of index.js altogether and only use > > the optional default arguments, so we don't have to initialize prefs twice (once > > in index.js and once in devtools/client/preferences). > > I agree it's not ideal, to have to duplicate a default value like that. Unfortunately, it's error-prone (as we've just seen here), it would be nice to start using devtools.js, or make devtools.js use index.js somehow. Anyway, I'm fine with just updating index.js for this bug.

Comment on attachment 8889823 [details] Bug 1384033 - initialize devtools.cache.disabled pref in netmonitor launchpad index; https://reviewboard.mozilla.org/r/160918/#review166298 Fixes launchpad for me. Thanks for taking a look!

Pushed by ntim.bugs@gmail.com: https://hg.mozilla.org/integration/autoland/rev/cece3bed8156 initialize devtools.cache.disabled pref in netmonitor launchpad index;r=ntim