While wrapping up the release for this month, I was noticed opening a saved fiddle in Firefox appeared to introduce a race condition. The error message in the console wasn’t much help. It just said “b is undefined” and a line of Google Closure compiled JavaScript. I used the JSBeautifier to find, actually guess, the line where the error occurred. So my hypothesis was that the result iFrame wasn’t loaded when the code needed it. Needless to say, loading iFrames using JavaScript was bad enough, and trying to detect when an iFrame is loaded using JavaScript is even worse:

It’s ideal if you can get the iframe to tell you itself from a script inside the frame. For example it could call a parent function directly to tell it it’s ready. Care is always required with cross-frame code execution as things can happen in an order you don’t expect.

Then I had a few genius ideas along with (oh, I had this working in an older version of the software) experience. So to get to the point, a Django Media Sync processor finally allowed me to view the source code while debugging on the actual site. In contrast to setting breakpoints on lines thousands of characters long and reading alphabetized code. Just spending about 5 minutes glancing at the documentation and looking at the file for Closure compiler, I put these lines in a file called combine in my “Python27\Lib\site-packages\mediasync\processors” folder:

After adding it in my settings file, running the media sync command, and refreshing; a nice error message showed up in the console. I could finally put debug points in the deployed, combined script files!

The trick with a media processor is that it can return false to just pass it along the pipe, so it can move through multiple processors, even Ruby’s SASS. I noticed this from the way the Closure compiler only returned for JavaScript files and by looking at the parameter names. This is really where well name functions and variables help. I don’t need to read the documentation to know what’s going on.