Yikes, what a debugging unfriendly codebase this site serves to us. :)
There are way too many setTimeout() calls to be looking at every single one. However, there is a hint in the console, a "TypeError: this is undefined" exception, but that's 51 frames deep in a stack full of wrapper functions.
This site seems to be using a framework on top of Backbone.js called Marionette, and the exception itself is happening in the
_proxyMethods function of a module called
Wreqr.Radio. This module is a global communication channel for components, so... that's fun. If we look at the unminified source for that function, we can see that this exception doesn't make sense here.
_proxyMethods gets called from within
Radios constructor, and they set
this up with some empty objects straight away. Inside the function, there are a couple of callbacks, but given they call Underscore.js's
each function, we should be somewhat confident that Underscore.js isn't messing with the scopes of these functions.
While looking at the stacks of calls to that
_proxyMethods method in both a "working" scenario (i.e., Firefox with
dom.timeout.defer_during_load turned off) and a "non-working" one, I noticed that the stacks look different. Early calls are identical, but as soon as we are within that method calling Underscore, we end up in different functions, one of which does things that end up breaking the scope of those callback functions.
And it turns out that the site is loading two versions of Lodash/Underscore, one in
libraries-d3479d7f4631b94864264fdd7bdf91f3.js (v3.10.1, which is the one that should normally be used), and the other one in
timeline-2.0.11.js (v4.17.10, which is used if the slider is broken). Both versions register themselves with the same name to the global RequireJS, so it's no wonder that some parts of the site suddenly end up somewhere else. I don't know exactly why they collide with each other in this way, but given it's one major version of Lodash apart, it's not surprising.
Although this is something the site could fix, it is still a bit concerning to me. The only asynchronous call in the whole stack here is a
setTimeout(fn, 4);. Unfortunately, this is RequireJS'
nextTick function. So while it is weird for a site to define the same module twice (with different versions), us delaying
setTimeout is somehow influencing RequireJS, although only in cases where a module is defined twice.