Posted on

Upgrade Issues from MooTools 1.2.4 to Mootools 1.3.2

This past week we worked on some site updates for Abundatrade.  During the updates we attempted to upgrade Mootools from 1.2.4 to 1.3.2.  Unfortunately this did not go as well as expected.  After 8 hours of trying to get it to work we ended up rolling back to Mootools Core 1.2.4 with Mootools More   Here are some of the pitfalls.

$empty Is Not Defined

The first problem was with the FormCheck library from   The library requires the “old-school” $empty function definition from MooTools.   This has been deprecated in later versions.   It also turns out it is a pain to replicate, though we were able to patch around this by adding a this.$empty function() {} definition to the JavaScript library.    After doing so we ran into more problems with undefined methods so we gave up and ended up loading MooTools Core 1.3.2 with compatibility.  That resolved both the $empty definition problem as well as some other issues we had with failing code.

Unintended Recursion

The bigger problem that forced us back to v1.2.4 was an unintended recursion problem in one of our AJAX calls that queues and consumes requests to/from a back-end server script that feeds JSON back into the main web document. With all versions up to 1.3.X the system works as we expect, you put in a UPC, click “Add Item”, it is sent to the back-end for real time pricing lookups, and a single row is added to an on-page table showing the item and the offer price. With version 1.3.2 the call to the back-end system is now working as a factorial function.  The first time you add an item you get one call to the back-end. The second time you get 2 calls, by the 6th added item you have a table full of duplicates that is growing exponentially. Not good.

We dug around for answers for most of the day yesterday, but nothing obvious was uncovered. The basic culprit is a form submit handler that eventually does something like this:

function MyHandler() {
… this.set(‘send’,func () { do stuff; });

The first time through it works perfectly. Subsequent iterations are looping through the this.set call, as if this is now an array of handler objects.  There must be a way to reset the form handler stack to be a single instance, but damned if we can find it. The problem appears to be triggered by a change in the MooTools library that now handles the anonymous function definition differently as it is no “array aware”.

MooTools 1.2.X Problems

Unfortunately, staying with MooTools 1.2.4 presents another problem.  The spinner class breaks for Internet Explorer 9.  With the spinner class in place the submit form handler fails.   Thus for MooTools 1.2.4 we are stuck with a subset of the UX.

The failing code:'top_content').set('spinner',



There is probably a design flaw in our code, but it is not easy to unwrap and simply turning on MooTools 1.3.2 with compatibility mode is not fixing it.  So much for the easy way out.  For now we’re back to MooTools 1.2.X and moving on.  Other projects await.   If you have any hints on what the issue may be please share.

One thought on “Upgrade Issues from MooTools 1.2.4 to Mootools 1.3.2

  1. Thanks!

Comments are closed.