721916 - Disable Map and Set for Firefox 12

Status: RESOLVED DUPLICATE of bug 723219

(Core :: JavaScript Engine, defect)

Description

[Jason Orendorff [:jorendorff]]

I only talked briefly with blizzard about this in #developers. Basically we're sure Map and Set will evolve some more in TC39 before they are standardized, and they may change in ways that aren't fully backward-compatible with what we've implemented.

(Map and Set are new JS builtins added in bug 697479.)

What to do is a product choice, not a JS choice. Chrome has them off by default, with a pref to enable them. Maybe we should do the same?

Comment 1

[David Mandelin [:dmandelin]]

My thoughts so far:

I had been assuming we'd try to scare people by saying "hey, this stuff isn't standardized yet, so feel free to play with it, but we'll feel free to change it according to the standard". But I guess no one is actually guaranteed to receive a message like that if we don't 'protect' the new features by something like prefixing or hiding them behind a pref.

I have no serious objections to requiring a pref to enable Map/Set. But I do note that if they are hidden in that way, then people can really only with them on their own--they can't build an app using Map/Set and put it out for others to try. Also, it may inhibit some people from playing with them. (We could try to help with that by making a Jetpack that turns on the pref.)

Comment 2

[Chris Leary [:cdleary] (not checking bugmail)]

I understand that in CSS they have to do things like prefixing because of the declarative nature of the environment, but in JS couldn't we do something like make a Mozilla object (a la the Math object) that permitted you to say |Mozilla.enableMapAndSet()| to activate those as "lazily initialized standard class"-like things?

Maybe introducing a name like that's not doable for some reasons that I'm unfamiliar with?

Comment 3

[Dave Herman [:dherman]]

(In reply to Chris Leary [:cdleary] from comment #2)
> I understand that in CSS they have to do things like prefixing because of
> the declarative nature of the environment, but in JS couldn't we do
> something like make a Mozilla object (a la the Math object) that permitted
> you to say |Mozilla.enableMapAndSet()| to activate those as "lazily
> initialized standard class"-like things?

I've wondered about creating a Moz or Mozilla object that serves as a namespace, but I would not use it to dynamically bind global objects. The web platform does way too much of that already. I'd simply put the bindings there, e.g. Moz.Map and Moz.Set.

The real question of course is whether we think binding provisional implementations of an emerging standard in a non-standard location is going to be effective.

Dave

Comment 4

[Jeff Walden [:Waldo]]

The lazy standard class stuff is a pain already.  Making it configurable at runtime would be a nightmare.

A simple solution to get some testing without locking ourselves in would be to enable things like this in the nightly tree, disable them a few days before merges, then reenable after merges.  Anyone who wants to experiment can do so with a nightly, and there's no danger of over-dependence because neither aurora nor beta will include the experiment.

Comment 5

[Jeff Walden [:Waldo]]

Regarding the "real question" from comment 3, I tend to think "not really".

Comment 6

[David Mandelin [:dmandelin]]

(In reply to Jeff Walden (remove +bmo to email) from comment #4)
> The lazy standard class stuff is a pain already.  Making it configurable at
> runtime would be a nightmare.
> 
> A simple solution to get some testing without locking ourselves in would be
> to enable things like this in the nightly tree, disable them a few days
> before merges, then reenable after merges.  Anyone who wants to experiment
> can do so with a nightly, and there's no danger of over-dependence because
> neither aurora nor beta will include the experiment.

I like it. How about enabling on Aurora too once we think the implementation is reasonably stable? That might help get a larger audience (for either Harmony or Aurora, either of which would be great).

Comment 7

[Jeff Walden [:Waldo]]

Progressive enabling sounds like a reasonable way to do it.

Comment 8

[Jason Orendorff [:jorendorff]]

Blizzard wants to be able to talk a little about Map and Set while they're in Aurora; he says it's totally cool to leave them in for a while if it's low-risk to disable them toward the end of the cycle or even during beta.

So my new plan is to post the (very-low-risk) patch to disable Map and Set here, get review, and let it sit for a few weeks.

Comment 9

[David Mandelin [:dmandelin]]

(In reply to Jason Orendorff [:jorendorff] from comment #8)
> Blizzard wants to be able to talk a little about Map and Set while they're
> in Aurora; he says it's totally cool to leave them in for a while if it's
> low-risk to disable them toward the end of the cycle or even during beta.
> 
> So my new plan is to post the (very-low-risk) patch to disable Map and Set
> here, get review, and let it sit for a few weeks.

I was just talking to Dave Herman about this, and based on that conversation, my latest thinking is that:

- We want to have a way to enable/disable the feature just for internal reasons (e.g., disable before release if needed to fix regressions).
- It would be great to have the new features just work at least through Aurora.
- We can think about Beta and release more when we get there. At least right now, I think it could be OK to just give people everything along with a message that the spec is not final--we could just be different from Chrome that way and see how we like it.

I think what I just said is consistent with what you just said, except that I think it also means we could go ahead and land the pref-ability right away, just have it default to 'on'.

Comment 10

[Philipp von Weitershausen [:philikon]]

I think pref-ability would be great. Also, it would be great if the pref-ability would only affect content and not chrome.