This appears to be some kind of build flow issue.  In a local build of trunk, 
this page works fine with no errors.

It's of course difficult to debug the inline JS which is compiled.

You can work around the bug by adding the 'debug' filter to the location blocks 
for your admin handlers your pagespeed.conf like this

    <Location /pagespeed_admin>
       Order allow,deny
        Allow from localhost
        Allow from 127.0.0.1
    SetHandler pagespeed_admin
    ModPagespeedEnableFilters debug
    </Location>
    <Location /pagespeed_global_admin>
        Order allow,deny
        Allow from localhost
        Allow from 127.0.0.1
    SetHandler pagespeed_global_admin
    ModPagespeedEnableFilters debug
    </Location>

This avoids the JavaScript error on this page.

We need to understand why the optimized JavaScript is failing.

Hello, this issue fix has been initiated after i have noticed it. 
So, after adding debug filter, it's working now, besides, i noticed that graphs 
started to work too.

So, i guess you guys should check that admin page too. Before it would say 
something like "refreshing..." and would never show any graphs.

Thank you for your work.

Debugging this is complicated by a recent change to use public closure-compiler 
to compile our JS, rather than Google's internal installation of that.

The 1.9 release version of MPS has very different JS fragments for caches.js 
(which is inlined) depending on whether or not debug mode is on.  The debug 
version works and the optimized version doesn't.

In trunk the two files are also different, but both of them work.  In debug 
mode you can also read the JavaScript if you visit:
   /pagespeed_admin/cache?PageSpeedFilters=+debug,-rewrite_javascript#purge_cache

I suspect we are getting lucky in the trunk build, and we are missing some kind 
of extern declaration to keep some symbols needed externally from being 
renamed.  It also might be 

This obviously worked in optimized mode when we were developing the feature.  
However it might be sensitive to closure-compiler flags.

Is the "@export" declaration above pagespeed.Caches.Start enough to keep it 
from being renamed?

I'll note that elsewhere in our JS we set string properties on window to export 
functions.  Maybe in our old flow @export did not work, but in our new flow it 
does?

I'm able to reproduce this failure with the compiled JS in 1.9. It looks like 
the error is actually occurring within closure/net/xhrio.js. It seems fixed in 
the newest versions, although I can't track down the specific change that broke 
or fixed it. If we want to do a point release, we can just copy 
net/instaweb/genfiles/cache_opt.js from trunk.

Resolved in r4372. This will be fixed in the next 1.9 point release.