While enabling mochitests on Firefox Mulet (bug 943878), I've seen exceptions in nsBrowserGlue migration code that prevents running the test suite. It is related to the fact that we set browser.startup.homepage to a string value "chrome://b2g/content/shell.html" in order to open Gaia by default. That makes the following code to throw when running mochitests: http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserGlue.js#1419 1421 let uri = Services.prefs.getComplexValue("browser.startup.homepage", 1422 Ci.nsIPrefLocalizedString).data;

Simple patch, just fall back to regular char pref, if complex one throws.

Similar patch for nsBrowserContentHandler

is there a reason you can't set it as a complex value? is the pref set through a pref.js file? may you set it through an head file? My only fear is that by relaxing the check we may end up with more code using unexpected value types, and that will soon or later enforce us to fix all of the code to do the same, rather than just these 2 points. Maybe I'm just over-zealus. You may just Services.prefs.setComplexValue("browser.startup.homepage", Ci.nsISupportsString, your_str);

I'm setting it in a pref.js file, like this: https://github.com/ochameau/mozilla-central/blob/mulet/b2g/app/b2g.js#L13 You are right, most production code assume it is a complex value. It looks like the only code that set it to a simple charpref is test code. Would there be a easy way to set it as a complex value from a pref.js file? It looks like it isn't supported: http://mxr.mozilla.org/mozilla-central/source/extensions/pref/autoconfig/src/prefcalls.js#25 Would you feel comfortable tweaking prefcalls.js??

Hum prefcalls.js doesn't seem to be used. Instead it looks like we are having a parser implemented in C++... http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefread.cpp It makes it no fun to support complex value in pref files!

That's the best solution I found :/ It looks like there is no way to overload browser.startup.homepage from a pref.js file. I thought pref.js files were just evaluated as javascript and prefcalls.js was implemeting pref and user_pref methods. But it looks like it isn't. Instead we have a C++ parser, that makes it significantly harder to improve. So given that this pref is read by a nsICommandLine xpcom, we can't easily set this pref in a chrome js file... We have to set it from an xpcom evaluated very early. If you know any way to set a complex pref in any other way, I would be pleased to submit a simplier patch!

Sounds like you want bug 721211! A simpler hackaround would be to specify it as a "localized" pref, since we initially try to retrieve the pref that way: pref("browser.startup.homepage", "data:text/plain,browser.startup.homepage=chrome://b2g/content/shell.html");

Comment on attachment 8415361 [details] [diff] [review] Override browser.startup.homepage in Mulet as a complex value (In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #8) > Sounds like you want bug 721211! > > A simpler hackaround would be to specify it as a "localized" pref, since we > initially try to retrieve the pref that way: > > pref("browser.startup.homepage", > "data:text/plain,browser.startup.homepage=chrome://b2g/content/shell.html"); Thanks for the pointer! I would rather prefer this hack than a component for that. Alexandre can you replace all your patch with this single line ?

Ok, that is pure magic. Thanks gavin for this tip! And yes, bug 721211, sounds like the sane way to go. You most likely want to use Homescreen.jsm also from browser/components/nsBrowserGlue.js as highlighted in attachment 8410985 [details] [diff] [review]. Otherwise you may have some exception while running mochitests.

Comment on attachment 8417410 [details] [diff] [review] Override browser.startup.homepage in Mulet as a complex value Review of attachment 8417410 [details] [diff] [review]: ----------------------------------------------------------------- So easy.

The dependency ends up being the other way around.