Having a non-enumerable Array.prototype.contains may not be web-compatible
Bug in MooTools is not a reason to make any method of Array.prototype enumerable.
On 9/30/14, 2:45 PM, Michał Wadas wrote:
Bug in MooTools is not a reason to make any method of Array.prototype enumerable.
I didn't say we need to make it enumerable.
I said that given the current state of the web, a web browser cannot ship a non-enumerable method named "contains" on Array.prototype.
The options, therefore, are:
- Make the method enumerable.
- Name the method something else.
- Don't ship the method until every site that currently uses the buggy versions of MooTools (which is every site that uses MooTools, since they only fixed it 4 days ago).
I'm perfectly fine with option 3, personally. Note that in practice that likely means "never ship it" unless people make some sort of concerted effort to get sites to update their MooTools version.
-Boris
P.S. It may be worth avoiding the method names mootools sets up but doesn't force-copy in the future. Even better would be getting them to fix their code so there are no such method names, of course.
"the current state of the web" ... with all due respect for that library, it's been years since I've heard anything about it.
It's also common on the old web to loop over Arrays via for/in to avoid
checks for sparse indexes through the entire length ... so making anything
enumerable in that native prototype would break something else too form
days where getOwnPropertyNames was unknown.
long story short: I definitively +1 what Michał Wadas already said, it's already patched and people must update software anyway due security problems, patches, etc etc.
just my .02
MooTools breaking because of additions/changes is not a new thing. It has been broken in the past by things like Function#bind, String#contains, & Moz removing document.getBoxObjectFor. Its activity has slowed overall though there is an effort to re-energize core contributions. Their core has put effort towards another project, Prime, which does not augment native prototypes.
The problem is not people actively developing it, or creating new content with it. The problem is existing content that might break. All libraries have periods where they are in vogue, and then fade out leaving detritus that hangs around for years/decades on major sites.
On Tue, Sep 30, 2014 at 3:45 PM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote:
"the current state of the web" ... with all due respect for that library, it's been years since I've heard anything about it.
Seconded—arguably MooTools' decline in usership is because of conflicts such as this.
On Tue, Sep 30, 2014 at 4:02 PM, Oliver Hunt <oliver at apple.com> wrote:
The problem is not people actively developing it, or creating new content with it. The problem is existing content that might break. All libraries have periods where they are in vogue, and then fade out leaving detritus that hangs around for years/decades on major sites.
In these cases, evangelism over the next two years will help. Most major sites are also maintained sites, which means there is time to work on getting the necessary fixes implemented.
Welp, nothing to do but add @@unMooToolsables.
On 9/30/14, 3:45 PM, Andrea Giammarchi wrote:
"the current state of the web" ... with all due respect for that library, it's been years since I've heard anything about it.
"They have ears, but cannot hear..."
This is a reasonably commonly used library, as libraries go.
On Tue, Sep 30, 2014 at 4:16 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
On 9/30/14, 3:45 PM, Andrea Giammarchi wrote:
"the current state of the web" ... with all due respect for that library, it's been years since I've heard anything about it.
"They have ears, but cannot hear..."
This is a reasonably commonly used library, as libraries go.
This may be helpful: trends.builtwith.com/javascript/javascript
Just a heads up, I've pinged MooTools core to inquire about fast-pathing a patch release for Array#contains.
On 9/30/14, 4:29 PM, Rick Waldron wrote:
This may be helpful: trends.builtwith.com/javascript/javascript-library
Rick, thank you!
This says 1.32% on top 10k sites, 3.05% on top 100k sites, 4.78% on top million sites, and 6.39% overall.
There's definitely been a recent dip in those numbers, of course. Used to be even higher.
On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas <michalwadas at gmail.com> wrote:
Bug in MooTools is not a reason to make any method of Array.prototype enumerable.
Well -- true, that would break even more sites.
We're backing out Array#contains() for now. It's disappointing to me personally -- that was a volunteer contribution. In the long run, perhaps renaming it is the best course? :-\
There is no need to change the name. MooTools has had these issues in the past (they've broke with ES5, ES6, & ES7 methods). Array#contains is ES7 so there's time for their patch to release/propagate.
I'm personally against unmaintained code and/or websites but here it's not ES7 breaking the web, it's a library already broken (somehow) due native prototype pollution without a mechanism to prevent these, apparently historically known, problems.
Should ES7 be planned around all methods already taken in there? I don't think so + it is also already patched and it's also a small fix.
If sites and developers have no reason to update code 'cause ES7 cannot release until they'll change a file ... why would they anyway.
Best
John-David Dalton wrote:
Just a heads up, I've pinged MooTools core to inquire about fast-pathing a patch release for Array#contains.
Did you ask them to fix their code so it doesn't fail for any name, not just for 'contains'? Thanks,
Did you ask them to fix their code so it doesn't fail for any name, not
just for 'contains'? Thanks,
I didn't, but will follow up with that.
JDD
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
I'm personally against unmaintained code and/or websites but here it's not ES7 breaking the web, it's a library already broken (somehow) due native prototype pollution without a mechanism to prevent these, apparently historically known, problems.
Either way, you're telling me I should ship a browser that chokes on thousands of web sites that work fine today. That would be bad for our users, so I'm not planning on doing that.
it is also already patched and it's also a small fix.
The 6.5% of existing web sites using JS libraries that use MooTools have not been "already patched". Patching 3.5 million web sites is not a "small fix" in any relevant sense. It simply will not be done thoroughly or soon.
If sites and developers have no reason to update code 'cause ES7 cannot release until they'll change a file ... why would they anyway.
Yes. You have correctly identified incentives as a problem.
That does not constitute a reductio proof that browser vendors must ignore their users' interests and break the web. "Reductio ad the-world-is-not-as-I-wish-it-to-be" is not a thing.
On Tue, Sep 30, 2014 at 6:04 PM, Jason Orendorff <jason.orendorff at gmail.com>
wrote:
On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas <michalwadas at gmail.com> wrote:
Bug in MooTools is not a reason to make any method of Array.prototype enumerable.
Well -- true, that would break even more sites.
We're backing out Array#contains() for now. It's disappointing to me personally -- that was a volunteer contribution. In the long run, perhaps renaming it is the best course? :-\
Unfortunately, it's named to match String.prototype.contains and Domenic
made strong cases in his proposal and presentation for contains over
alternatives
On Tue, Sep 30, 2014 at 7:24 PM, Jason Orendorff <jason.orendorff at gmail.com>
wrote:
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
I'm personally against unmaintained code and/or websites but here it's not ES7 breaking the web, it's a library already broken (somehow) due native prototype pollution without a mechanism to prevent these, apparently historically known, problems.
Either way, you're telling me I should ship a browser that chokes on thousands of web sites that work fine today. That would be bad for our users, so I'm not planning on doing that.
I support your decision to back it out for now and the foreseeable future. This will give devs a chance to evangelize the necessary updates.
So put ES7 features behind a flag until the water clears a bit. We'll get there. It kind of surprises me (a good surprise) that now, because of JSFiddle, there's super interest in MooTools. When in the past, when MooTools was arguably more popular, it didn't stop the language and browsers from breaking them over and over again.
JDD
You guys are much more optimistic than I am about this ever being shippable. I am starting a new thread to investigate solutions that don’t involve waiting for indeterminate amounts of time, but of course if we can somehow fix the MooTools-using web and not change anything about Array.prototype.contains, that would be ideal.
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of John-David Dalton Sent: Wednesday, October 1, 2014 00:55 To: Jason Orendorff Cc: es-discuss Subject: Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
So put ES7 features behind a flag until the water clears a bit. We'll get there. It kind of surprises me (a good surprise) that now, because of JSFiddle, there's super interest in MooTools. When in the past, when MooTools was arguably more popular, it didn't stop the language and browsers from breaking them over and over again.
JDD
On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff <jason.orendorff at gmail.com<mailto:jason.orendorff at gmail.com>> wrote:
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com<mailto:andrea.giammarchi at gmail.com>> wrote:
I'm personally against unmaintained code and/or websites but here it's not ES7 breaking the web, it's a library already broken (somehow) due native prototype pollution without a mechanism to prevent these, apparently historically known, problems.
Either way, you're telling me I should ship a browser that chokes on thousands of web sites that work fine today. That would be bad for our users, so I'm not planning on doing that.
it is also already patched and it's also a small fix.
The 6.5% of existing web sites using JS libraries that use MooTools have not been "already patched". Patching 3.5 million web sites is not a "small fix" in any relevant sense. It simply will not be done thoroughly or soon.
If sites and developers have no reason to update code 'cause ES7 cannot release until they'll change a file ... why would they anyway.
Yes. You have correctly identified incentives as a problem.
That does not constitute a reductio proof that browser vendors must ignore their users' interests and break the web. "Reductio ad the-world-is-not-as-I-wish-it-to-be" is not a thing.
many MDN examples are on jsfiddle ...maybe one of the reasons? Although I wasn't suggesting to break everything, rather saying that changing name should not be an option.
FYI: from a MooTools core developer: gist.github.com/fakedarren/28953b01e455078fb4f8
Just to close this chapter/thread with some external outcome.
Old sites with old version of Mootools will have problems when trying to use native Array.prototype.contains. Is that the only problem or is there something else I'm missing?
On 10/7/14, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
FYI: from a MooTools core developer: gist.github.com/fakedarren/28953b01e455078fb4f8
The article has a few issues. Array.prototype.forEach landed in Mozilla before 2006, and there are still libraries that modify DOM prototypes. Polymer, by the former Bindows author, is one. Modifying built-in Array.prototype for GP scripts was never a good idea. And the gist misses the big point that modifying objects that you don't own, you risk issues with forwards compatibility. Here it is now, at forward compatibility issue point. The ideas were bad at the time. I criticized them pretty heavily around 2007 for these ideas and they complained on my blog. Now, they are congratulating themselves on their efforts, and blaming Microsoft for forcing them to make those mistakes.
Mootools' contains be refactored and that's what the good folks at this thread brought up. MooTools can do a conditional check with a feature test, create a replacement alternative for their own methods, and deprecate, for future removal, MooTools' custom Array.prototype.contains in favor of something that is not incompatible.
This situation reminds me of the W3C proposal for Event creation to
use Event constructor, regardless of Mootools already having defined
a global Event constructor for the web.
That w3c proposal was adopted and implemented, probably with compat
issues, seeing as MooTools has removed their Event for their new
global DOMEvent function, deprecated their global Event function,
kept it for backwards compatibility, and then removed it in a
subsequent release.
Their replacement's name "DOMEvent" starts with "DOM" and there is no guarantee that the w3c won't define a new type of event called DOMEvent (maybe to describe DOM Mutation). MooEvent is a more intentional and a better name.
But anyway, MooTools, can with their Array.prototype.contains what they did with their Event. Maybe with a better name or maybe using another typeof approach than "rename".
jsfiddle.com, lists.w3.org/Archives/Public/public-script-coord/2011JulSep/0115.html, www.twitlonger.com/show/bd2994
See bugzilla.mozilla.org/show_bug.cgi?id=1075059 for a case it breaks, for example.