905660 - it should be much easier to put a feature behind a dynamic pref

Status: RESOLVED DUPLICATE of bug 1877193

(Core :: JavaScript Engine, defect)

Description

[Luke Wagner [:luke]]

The pattern which we and other browsers have moved / are moving to for experimental feature development is to put the feature behind a dynamic pref which is default 'off' on some subset of {nightly,aurora,beta,release} and then, when appropriate, start flipping the defaults to 'on'.  This is nicer than having a compile-time flag which is only #defined on some release channels, but it's a real pain to do now: just look at http://mxr.mozilla.org/mozilla-central/search?string=JSOPTION_ION.  You have to add something to prefs.js, figure out the magic #ifdefs to control the default value, add a JSOPTION_*, and then toggle this option from dom/nsJSEnvironment, worker/RuntimeService, the JS shell, xpcshell, and maybe the Components object.

Ideally, we'd maintain a table of these prefs and their defaults on the different branches inside the JS engine and all the places listed above would generically operate on JS prefs via this table.  (Note: we should still be able to efficiently test a pref by testing a bit on the JSRuntime.)

Filing this now because there are at least 4 features in progress that we probably want to pref in this manner: BinaryData, value objects, PJS, SIMD.