Mootools and String.prototype.contains

# David Bruant (13 years ago)

I was looking at Bugzilla and came across two bugs [1] [2] related to Mootools-based (only Mootools 1.2-) websites being broken by the inclusion of String.prototype.contains in SpiderMonkey. I don't think it's been brought to the list yet, though I think it's relevant.

David

[1] bugzilla.mozilla.org/show_bug.cgi?id=781796 [2] bugzilla.mozilla.org/show_bug.cgi?id=789036

# Yusuke Suzuki (13 years ago)

Hello,

I've found the issue in mootools-core [1].

[1] mootools/mootools-core#2402

, Yusuke Suzuki

# Alex Russell (13 years ago)

It's unclear what we should do here. Their test-and-install mechanism was overly optimistic and therefore future hostile. It looks as though outreach is happening and they're fixing their library and aligning with ES6 in future releases.

My suggestion is to wait-and-see what browser vendor advocacy can accomplish without either changing the name of contains() in the drafts or removing it.

# Geoffrey Sneddon (13 years ago)

On 12/10/12 14:50, David Bruant wrote:

I was looking at Bugzilla and came across two bugs [1] [2] related to Mootools-based (only Mootools 1.2-) websites being broken by the inclusion of String.prototype.contains in SpiderMonkey. I don't think it's been brought to the list yet, though I think it's relevant.

Given there were similar issues with Function.prototype.bind in the same release of Mootools, I'm inclined to let it slide: Mootools 1.2 already broke given ES5, and that was pushed through regardless.

# Alex Russell (13 years ago)

Good context. I didn't know that they had b0rked bind() as well ;-)

I feel like there's as PSA we should write over on webplatform.org for library authors about how to not be future hostile.

# Rick Waldron (13 years ago)

On Fri, Oct 12, 2012 at 10:09 AM, Alex Russell <slightlyoff at google.com>wrote:

It's unclear what we should do here. Their test-and-install mechanism was overly optimistic and therefore future hostile. It looks as though outreach is happening and they're fixing their library and aligning with ES6 in future releases.

My suggestion is to wait-and-see what browser vendor advocacy can accomplish without either changing the name of contains() in the drafts or removing it.

I agree. ES6 standardization isn't due until Dec 2013, which gives browser vendors and lib authors over a year to "spread the word", fix implementations, update code, etc.

# David Bruant (13 years ago)

2012/10/12 Geoffrey Sneddon <gsneddon at opera.com>

On 12/10/12 14:50, David Bruant wrote:

I was looking at Bugzilla and came across two bugs [1] [2] related to Mootools-based (only Mootools 1.2-) websites being broken by the inclusion of String.prototype.contains in SpiderMonkey. I don't think it's been brought to the list yet, though I think it's relevant.

Given there were similar issues with Function.prototype.bind in the same release of Mootools, I'm inclined to let it slide: Mootools 1.2 already broke given ES5, and that was pushed through regardless.

By intuition, I'd say there is much more code with mystring.contains than uses of myfunction.bind and so pushing .contains may have more impact than .bind did. But that's just an intuition.

# Geoffrey Sneddon (13 years ago)

On 13/10/12 11:47, David Bruant wrote:

2012/10/12 Geoffrey Sneddon<gsneddon at opera.com>

On 12/10/12 14:50, David Bruant wrote:

I was looking at Bugzilla and came across two bugs [1] [2] related to Mootools-based (only Mootools 1.2-) websites being broken by the inclusion of String.prototype.contains in SpiderMonkey. I don't think it's been brought to the list yet, though I think it's relevant.

Given there were similar issues with Function.prototype.bind in the same release of Mootools, I'm inclined to let it slide: Mootools 1.2 already broke given ES5, and that was pushed through regardless. By intuition, I'd say there is much more code with mystring.contains than uses of myfunction.bind and so pushing .contains may have more impact than .bind did. But that's just an intuition.

My memory was Mootools itself depended on bind, so it was significantly more that broke, thus my conclusion. Someone (probably me!) should check what it was that actually broke, exactly. :)

# Sebastian Markbåge (13 years ago)

My memory was Mootools itself depended on bind, so it was significantly more that broke, thus my conclusion. Someone (probably me!) should check what it was that actually broke, exactly. :)

Many things in MooTools Core depends on itself. mootools/mootools-core/commit/c8dc1ab7ab09cc82d20c0bd3b3e9d0e7aba92204

There are some critical features of MooTools that used the contains method back then: mootools/mootools-core/blob/3e7459cb4756475a80921bfde5c19a7c7edb64df/Source/Element/Element.js#L419