Bug 730873 adds a move() operation to typed arrays. It may need to be preffed off (see bug 730873 comment 20 and following). We should add a way to do that easily, and for now we'll plan on turning it off before release.

Since this landed in the 16 cycle, it needs to be turned off before 16 ships, I believe.

We'll track then to see that this is turned off, can someone be assigned to this and have a patch ready with approval nom?

Waldo would be the natural one for r?, but he's partially out right now. This patch leaves move() enabled, but adds a way to disable in one line.

And this one does the actual disable.

Comment on attachment 660614 [details] [diff] [review] Add easy way to disable typed array move() method [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 730873 User impact if declined: a move() method that is not part of the any spec will be exposed to web content, allowing web developers to start creating potential backwards-compatibility problems. Testing completed (on m-c, etc.): local testing, very recently landed on m-i. Risk to taking this patch (and alternatives if risky): extremely low. Applying this patch does not change the preprocessed code at all. The followup patch is needed to actually change something. String or UUID changes made by this patch: none

Comment on attachment 660606 [details] [diff] [review] Disable typed array move() command [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 730873 User impact if declined: new method move() on typed arrays exposed to web content. move() is not yet part of any spec, so exposing it introduces backwards compatibility risk. Testing completed (on m-c, etc.): local only (for now, this should only land on beta since we want to leave the new method enabled on aurora) Risk to taking this patch (and alternatives if risky): Minimal String or UUID changes made by this patch: none This patch requires the other patch in this bug, which added the ENABLE_TYPEDARRAY_MOVE preprocessor macro.

Requesting tracking flags for 17 and 18 as well, since this will still be an issue until move() is added to the spec or people agree that we can add it in.

https://hg.mozilla.org/releases/mozilla-aurora/rev/e237933d2b08 (only the addition of the #define; still enabled on aurora)

https://hg.mozilla.org/releases/mozilla-beta/rev/9faa4ad41e23 https://hg.mozilla.org/releases/mozilla-beta/rev/b5c1c48202a7

Messed up the rebase for beta. https://hg.mozilla.org/releases/mozilla-beta/rev/2f8a5f915a15

Scoobidiver: are those status markings accurate? This feature is *not* yet disabled for either 17 or 18, and we don't know yet know whether we want it to be enabled or disabled. To the naive observer (namely, me), tracking-firefox17+ and status-firefox17=fixed implies that nothing else needs to be done. Should I open a separate bug?

(In reply to Steve Fink [:sfink] from comment #14) > Scoobidiver: are those status markings accurate? This feature is *not* yet > disabled for either 17 or 18, and we don't know yet know whether we want it > to be enabled or disabled. In Aurora, the changeset is http://hg.mozilla.org/releases/mozilla-aurora/rev/e237933d2b08 that matches the second patch. In Beta, they are http://hg.mozilla.org/releases/mozilla-beta/rev/9faa4ad41e23 (second patch), http://hg.mozilla.org/releases/mozilla-beta/rev/b5c1c48202a7 (first patch), and http://hg.mozilla.org/releases/mozilla-beta/rev/2f8a5f915a15 (second patch partially backed out). > tracking-firefox17+ and status-firefox17=fixed implies that nothing else > needs to be done. Should I open a separate bug? Yes because these patches are such a mess it's hard to follow.