There's been a lot of bugs filed (some bad ones) in regards to forgetting to include X default pref in the desktop web runtime that was included in desktop firefox by default. In an effort to avoid guessing what prefs we are missing in the desktop web runtime, I'd suggest instead conducting a review of known prefs that exist in desktop firefox, indicate which ones should be in the desktop web runtime, but are missing, and add those prefs and any other supporting code changes needed to get our default prefs for the desktop web runtime more correct by default. Ben suggested for example that we might consider adding the default prefs for plugins here - http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js?mark=898-911#898, so that's one area to consider. WebRT prefs.js: http://mxr.mozilla.org/mozilla-central/source/webapprt/prefs.js

I haven't seen any discussion on hotfixes (which basically work just a special-cased add-on), and whether it makes sense to have that concept in WebAppRT. But we could include the relevant prefs (extensions.hotfix.*) just in case. However, it requires app update to be enabled - app.update.enabled and app.update.auto to be both set to true. But it won't actually do any app update checks if app.update.url isn't set, so I think that's fine (probably want to confirm that with rstrong). Would also need to set extensions.update.background.url (same value as Firefox has). And AMO would at least need to reserve the hotfix ID (I'd suggest webapprt-hotfix@mozilla.org). I believe all the other relevant Add-on Manager related prefs are accounted for. The problem with prefs like bug 771817 is that they aren't typically used, and aren't used by Firefox - but I've gone through the code just in case I forgot something else, and didn't see anything.

Some other candidates: * general.autoScroll * dom.disable_window_status_change, dom.disable_window_flip, etc * mousewheel.* * browser.safebrowsing.* and urlclassifier.*

It would also be useful to look at the prefs that B2G/Gaia sets. But it isn't a top priority at the moment. Nevertheless, individual prefs might prove to be particularly important, so please do file bugs on specific prefs that you think we should prioritize!

Are the prefs inherited from Firefox (desktop)? Then add/overwrite some properties that are specific to webRT or should be set differently than for desktop (e.g. addons). I suspect that would be cleanest way.

(In reply to Florian Bender from comment #4) > Are the prefs inherited from Firefox (desktop)? No, the runtime inherits the GRE preferences (as does Firefox), but it doesn't inherit Firefox's own preferences.

Can we move more preferences "upstream" (i.e. to GRE preferences)? Or can we simply inherit the Firefox prefs and then override the necessary properties? IMHO the WebRT should be as close to the browser as possible, and keeping both files in sync looks like a very bad pitfall (especially for WebAPI prefs that are only enabled for some platforms, so they may be disabled in the WebRT while the browser has them enabled)!

I don't think we want to inherit Firefox prefs, but moving prefs upstream may be possible depending on the pref. Also we could have a separate file specific to webapprt, although we'd need to add a little extra code to load it in the stub, but that wouldn't be too hard.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #7) > I don't think we want to inherit Firefox prefs, but moving prefs upstream > may be possible depending on the pref. Also we could have a separate file > specific to webapprt, although we'd need to add a little extra code to load > it in the stub, but that wouldn't be too hard. I agree, browser preferences should be different because a browser is different than a single app (for example we don't have bookmarks in the webrt). We have a separate prefs file for the runtime (for example we're enabling mozPay and TCPSocket, that are disabled in Firefox): https://mxr.mozilla.org/mozilla-central/source/webapprt/prefs.js

I just noticed, that in the runtime specific prefs, there is no device.storage.enabled pref. Does that mean, that the Device Storage API is never accessible from the WebRT? Not even for privileged apps with the respective permissions in the manifest?

(In reply to tuxor from comment #9) > I just noticed, that in the runtime specific prefs, there is no > device.storage.enabled pref. Does that mean, that the Device Storage API is > never accessible from the WebRT? Not even for privileged apps with the > respective permissions in the manifest? It isn't yet. Bug 1046258 is about supporting the device storage API in the webapp runtime.

Per bug 1238079, we're going to disable the desktop web runtime and remove it from the codebase, so we won't fix these bugs in it.