On Thu, Oct 2, 2014 at 4:51 PM, Ehsan Akhgari <[email protected]> wrote:
> On 2014-10-02, 9:58 AM, Till Schneidereit wrote: The full answer to that is actually ridiculously complicated. The part >> relevant here is, though: very early on in at least some cases. Too >> early to rely on preferences, if I'm not mistaken. I think the only >> reliable way would be to do it when creating the runtime. >> > > So, I took a quick look, and we create the first JSRuntime during the > initialization of XPConnect, which is *way* after the XPCOM stuff required > for the preferences service is initialized (I did verify that the > preferences service is initialized before we create the runtime.) > Ah, I was mistaken then, nice! > > Now, of course, there is no XPCOM (and no preferences service) in the js > shell, but it seems like if we wanted to support preferences for this > purpose for browser builds, the XPCOM side of things is not going to be an > issue. > I don't think we need to care about the shell at all. It can just always have all features. > I really dislike the idea of having a single pref which enables all kinds > of random features. I think we could definitely build a UI on top of our > existing experimental prefs if we decided that we wanted that, but I'd hate > to lose the granularity of having one pref per feature. That being said, > having one pref to control all experimental JS features sounds less bad to > me. :-) > Sorry, I did mean JS features, not All The Things. On Thu, Oct 2, 2014 at 4:55 PM, Bobby Holley <[email protected]> wrote: > On Thu, Oct 2, 2014 at 4:51 PM, Ehsan Akhgari <[email protected]> > wrote: > (Of course, I have no idea whether you'd be OK with just calling the > Preferences API inside the js code or if we need to invent some kind of a > way to mask that away, and just pass the necessary info into the JS engine > from the browser, and I have no idea how much work that would be, but I > think at least the first option is readily available if we decide to do > that.) > > I think the correct thing to do would be to have XPConnect query these > prefs and then set them on the runtime. If we wanted to, we could keep > per-compartment state, have XPConnect monitor the pref and update the > runtime, and have the runtime propagate the current bits to each > compartment at creation time. This would let the pref would work for new > compartments sans restart. > Yes, that'd probably be the way to do this. I'm not sure how important the runtime updating part is, though. _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
