On 2014-10-02, 9:58 AM, Till Schneidereit wrote:
On Wed, Oct 1, 2014 at 7:51 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com
<mailto:ehsan.akhg...@gmail.com>> wrote:
On 2014-10-01, 1:20 PM, Till Schneidereit wrote:
That's a great point. It would be great if we can adopt
https://wiki.mozilla.org/__WebAPI/ExposureGuidelines
<https://wiki.mozilla.org/WebAPI/ExposureGuidelines> for new JS
fatures as well.
Yes, I think we should consider that. The situation is somewhat
different in that we usually only implement features that are
stable,
specced, and agreed upon by tc39 and thus have buy-in by other
vendors.
("Usually" because we do some experimental Nightly-only stuff,
but that
is so exotic, really, that FF devs wouldn't begin to think that it's
production-usable.)
Sure, but I think it would still be valuable, even if it's only used
as an announcement mechanism.
I agree, and will bring it up with other SpiderMonkey devs.
Thank you!
Also, out of curiosity, do we have ways of hiding JS built-ins
behind prefs similar to DOM APIs?
Not really: by the time the prefs are read, we have already created
globals, so those either have the builtins (if we default to
installing
them) or won't ever get them, regardless of the pref's value (if we
default to not installing them).
Hmm.. I'm not sure about the details of the code in question. Is
this easy to solve? At what point exactly during startup do we
create those built-ins?
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.)
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.
(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.)
Also, I think there is great value in having these features
available
without a pref. Chrome uses prefs, and I think is substantially
diminishes the value for testing things out.
Array.prototype.contains is
a good example for that: if it had been behind a pref, who knows
when
we'd have discovered the web breakage?
I was not suggesting that we should have landed
Array.prototype.contains behind a pref. However, there are other
uses for being able to hide things behind a pref. One great example
is this pattern:
#ifdef NIGHTLY_BUILD
pref("what.ever", true);
#else
pref("what.ever", false);
#endif
This basically ensures that we don't accidentally end up letting the
feature slip past Nightly before we're "ready" (part of the
definition of ready might be, knowing that the feature is Web
compatible, etc.)
Inside SpiderMonkey, we ensure that by doing the Nightly check where the
feature is compiled/installed in the first place. For
Array.prototype.contains, that is here:
http://mxr.mozilla.org/mozilla-central/source/js/src/jsarray.cpp?rev=020a62efb303#3027
Oh, cool, I didn't know that.
Now that obviously doesn't allow you to manually enable these features
on Aurora and above. Assuming that you'd want to be able to do that in a
fine-grained way, the prefs thing would be even more complicated: we'd
have to add a way for the JS engine to query prefs, because just passing
in all of them from the outside becomes untenable. One thing that would
be possible, I suppose, is to have a single flag "enable experimental
extensions", as Chrome does. We should at least consider doing that,
without changing our current behavior of having these features enabled
by default on Nightly.
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. :-)
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
