Closed Bug 1000122 Opened 6 years ago Closed 6 years ago
.html as default homepage in Mulet .
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!
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 firstname.lastname@example.org) 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.
Summary: mochitests fail to launch if browser.startup.homepage isn't localized pref → Set shell.html as default homepage in Mulet.
Component: Bookmarks & History → Runtime
Product: Firefox → Firefox OS
Attachment #8417410 - Flags: review?(21)
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.
Attachment #8417410 - Flags: review?(21) → review+
The dependency ends up being the other way around.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S1 (9may)
You need to log in before you can comment on or make changes to this bug.