The default bug view has changed. See this FAQ.

MooTools 1.2.x was broken by adding String.prototype.contains

RESOLVED FIXED

Status

Tech Evangelism Graveyard
English US
RESOLVED FIXED
5 years ago
5 months ago

People

(Reporter: Benjamin, Unassigned)

Tracking

({site-compat})

Details

(Whiteboard: fixed by MooTools 1.2.6 (and higher))

(Reporter)

Description

5 years ago
This is a meta bug for breakage caused by bug 772733's addition of String.prototype.contains. MooTools defines a incompatible version of String.prototype.contains. Versions of MooTools greater than 1.2 override the builtin implementation, but 1.2.x assumes it is a compatible implementation. Upgrading to any later version of MooTools fixes the problem.

A MooTools bug has been filed:
https://github.com/mootools/mootools-core/issues/2402
(Reporter)

Updated

5 years ago
No longer blocks: 772733
(Reporter)

Updated

5 years ago
Blocks: 772733
Do we know how widespread this breakage is? MooTools claims to have somewhere between 5-8% marketshare, it's probably realistic that quite some of those aren't updating their framework regularly, if at all.

This might end up breaking a reasonable (>1%) amount of sites...
(Reporter)

Comment 2

5 years ago
For historical information about a similar snafu with Function.prototype.bind, see bug 784280 comment #10.
(Reporter)

Updated

5 years ago
Depends on: 789093

Updated

5 years ago
Depends on: 790462

Updated

5 years ago
Depends on: 791980
I think we should strongly consider disabling this on beta to avoid the breakage for the moment while continuing to evangelize the sites involved....
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
(Reporter)

Comment 4

5 years ago
It's not in beta yet, but yes I agree. We can wait at least another month, though.
tracking-firefox16: ? → ---

Comment 5

5 years ago
(In reply to Benjamin Peterson [:benjamin] from comment #4)
> It's not in beta yet, but yes I agree. We can wait at least another month,
> though.

I don't want our users to have a bad beta experience (even for a couple of betas), unless we think it's the only leverage for sites to fix. Were you thinking about fixing it for FF16b1 or later?
tracking-firefox17: ? → +
tracking-firefox18: ? → +
(Reporter)

Comment 6

5 years ago
(In reply to Alex Keybl [:akeybl] from comment #5)
> (In reply to Benjamin Peterson [:benjamin] from comment #4)
> > It's not in beta yet, but yes I agree. We can wait at least another month,
> > though.
> 
> I don't want our users to have a bad beta experience (even for a couple of
> betas), unless we think it's the only leverage for sites to fix. Were you
> thinking about fixing it for FF16b1 or later?

I propose beta 2 or 3.
Our "beta"s are actually release candidates.  That's how we're pitching them, and that's how we should treat them.

We shouldn't be shipping known bugs on beta if we can avoid it, imo.  That's what Aurora is for...
(Reporter)

Comment 8

5 years ago
I should note browser JS has started depending on contains.
That's even more of a reason to not ship it in beta.

In fact, if extensions are going to depend on it, then we can't ship it in beta, and ideally shouldn't be shipping it in Aurora, because we have extension compat promises we make with Aurora and beta builds...
(In reply to Boris Zbarsky (:bz) from comment #9)
> In fact, if extensions are going to depend on it, then we can't ship it in
> beta, and ideally shouldn't be shipping it in Aurora, because we have
> extension compat promises we make with Aurora and beta builds...

Extensions don't have to depend on it unless they specifically opt in.  Seeing as we didn't tell extension authors about any of the new string methods (going by bug 772733 still having dev-doc-needed, and there not being a page for String.prototype.contains yet, and if I say anything more right now I'm going to sound disturbingly like philor), and seeing as if they're targeting nightly or Aurora I think we have to presume they know they're playing with fire, I don't see that we need to disable this in Aurora too.
I can sort of buy that.  For beta, though, we promise extensions basically no breaking change of any sort after beta1, unless it's fixing a stop-ship bug kinda thing.  So we absolutely need to disable the string methods before going to beta.
(In reply to Boris Zbarsky (:bz) from comment #9)
> That's even more of a reason to not ship it in beta.
> 
> In fact, if extensions are going to depend on it, then we can't ship it in
> beta, and ideally shouldn't be shipping it in Aurora, because we have
> extension compat promises we make with Aurora and beta builds...

I agree with this. Nobody's made the case for how trying to leverage beta to get a MooTools fix outweighs the add-on/browser risk to disabling later in the cycle. I'll clone for the in-product change and leave this open for TE.

Updated

5 years ago
Blocks: 793781
(Reporter)

Comment 13

5 years ago
Fixed in bug 793781 for 17, so untracking there.
tracking-firefox17: + → ---

Updated

5 years ago
Depends on: 801311

Comment 14

5 years ago
I've added a section on MDN on the topic https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/String/contains#Broken_websites_with_MooTools_1.2_and_incompatible_signature_with_MooTools_1.3.2B
tracking-firefox19: --- → ?

Updated

5 years ago
Depends on: 805389

Updated

5 years ago
tracking-firefox19: ? → +
Untracking in favor of bug 793781.
tracking-firefox18: + → -
tracking-firefox19: + → -

Updated

4 years ago
Depends on: 812578
(Reporter)

Comment 16

4 years ago
MooTools 1.5 will have a ES6 compatible contains signature!

https://github.com/arian/mootools-core/commit/f9307e0c9dcae6a63b8f905c0b977368179d3d8b
Hey guys, I used to slang code for MooTools and I can run point on contacting and coordinating with them to address this. What is the honeymoon scenario we're looking for here?
(Reporter)

Comment 18

4 years ago
Ideally, all the dependent bugs would be closed. :) I've tried to contact them all, but feel free send your own.
(Reporter)

Updated

4 years ago
Depends on: 821175
Looks like we shipped this breakage in Firefox 18.  Just for post-mortem purposes, was that a conscious decision, or did it just slip through the cracks?
Documented at <https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_18#Mootools_1.2.x_is_not_compatible_with_Firefox_18_and_newer>.  If we _did_ ship this on purpose, I'd like to understand why we didn't bother documenting it or relnoting it or anything.
(Reporter)

Comment 21

4 years ago
It was a conscious decision. At least in the case of HP, they told me several times they were going to fix it by now. Trust but verify, I suppose.
OK.  Next time we ship something like this on purpose, please make sure it's relnoted and documented in our site compat docs, ok?

Updated

4 years ago
Depends on: 829384
Depends on: 829118
(In reply to :Benjamin Peterson from comment #21)
> It was a conscious decision. At least in the case of HP, they told me
> several times they were going to fix it by now. Trust but verify, I suppose.

HP is just one instance of the problem. Why should Firefox risk losing market share to take this hit? We need to push back in Ecma TC39 and get other browsers making the same change *after* a coordinated evangelism effort.

Should this get disabled in 18.0.1? It seems so from all the comments here.

/be
(Reporter)

Comment 24

4 years ago
(In reply to Brendan Eich [:brendan] from comment #23)
> (In reply to :Benjamin Peterson from comment #21)
> > It was a conscious decision. At least in the case of HP, they told me
> > several times they were going to fix it by now. Trust but verify, I suppose.
> 
> HP is just one instance of the problem. Why should Firefox risk losing
> market share to take this hit? We need to push back in Ecma TC39 and get
> other browsers making the same change *after* a coordinated evangelism
> effort.

Push back into ECMA TC39 for what?

> 
> Should this get disabled in 18.0.1? It seems so from all the comments here.

I don't think I'm one to make such a decision. I should not it's not completely trival because chrome code is using contains().
Depends on: 830189

Updated

4 years ago
Depends on: 830130
Depends on: 830779
Depends on: 831388
(Reporter)

Updated

4 years ago
Depends on: 828326
Duplicate of this bug: 834306
Duplicate of this bug: 835051

Comment 27

4 years ago
I am from support and don't see a lot of users complaining about this issue
Version: unspecified → Trunk

Comment 28

4 years ago
(In reply to David Weir (satdav) from comment #27)
That's probably because a lot of the users haven't upgraded to version 1.8 and haven't visited a site using mootools 1.2xx

You can see an issue here; try replying to this - http://www.techrepublic.com/forum/discussions/103-401241, firefox is failing to getParent(<selector>)

Here's another example, the social toolbar here [http://www.techrepublic.com/blog/window-on-windows/the-first-10-things-you-should-do-to-a-new-windows-8-desktop-installation/6467] should have a more button at the end. Check it out in other browsers or older versions of firefox
Go to http://foto-treff-bielefeld.de/
try to visit any link from black navigation bar
if you click, nothing happening
Blocks: 835051
(Reporter)

Updated

4 years ago
No longer blocks: 835051
Depends on: 835051
Duplicate of this bug: 834306

Updated

4 years ago
Depends on: 836667
(In reply to Brendan Eich [:brendan] from comment #23)
> (In reply to :Benjamin Peterson from comment #21)
> > It was a conscious decision. At least in the case of HP, they told me
> > several times they were going to fix it by now. Trust but verify, I suppose.
> 
> HP is just one instance of the problem. Why should Firefox risk losing
> market share to take this hit? We need to push back in Ecma TC39 and get
> other browsers making the same change *after* a coordinated evangelism
> effort.
> 
> Should this get disabled in 18.0.1? It seems so from all the comments here.
> 
> /be

As this affects quite old version of the MooTools library, specifically the 1.2.x branch which is now ~5 years old, MooTools will be releasing a 1.2.6 for that legacy code which corrects the issue for MooTools users. the 1.3+ branches of the library are all fine and have had no issues.

We'll need to updated our engagement actions on this front and push people to the new version. There's a blog post imminent that will describe all of this and includes the new code, I'll link to it here as soon as it's released.

Comment 32

4 years ago
MooTools 1.2.6 Released: http://mootools.net/blog/2013/02/19/mootools-1-2-6-released/
This is a new maintenance release for the old 1.2 series. The new ECMAScript 6 specification has a proposal for String.prototype.contains that unfortunately conflicts with the MooTools implementation of contains.
Firefox 18 already ships this new version of contains. This is not a problem for MooTools 1.3.x and onward, but this breaks MooTools 1.2.5, especially the code inside the MooTools framework that utilized this method, like selectors.
Whiteboard: fixed by MooTools 1.2.6 (and higher)

Updated

4 years ago
Depends on: 858943
This can be resolved since MooTools shipped the fix already..
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Updated

4 years ago
Keywords: site-compat
Product: Tech Evangelism → Tech Evangelism Graveyard
tracking-firefox18: - → ---
tracking-firefox19: - → ---
See Also: → bug 1103588, bug 1102219
You need to log in before you can comment on or make changes to this bug.