New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

purge cache UI has problems in dev console #1025

Closed
GoogleCodeExporter opened this Issue Apr 6, 2015 · 9 comments

Comments

Projects
None yet
1 participant
@GoogleCodeExporter
Copy link

GoogleCodeExporter commented Apr 6, 2015

console says this when you bring up /pagespeed_admin/cache#purge_cache

Uncaught ReferenceError: wa is not defined     cache:225
W.send                                         cache:225
k.v                                            cache:235
(anonymous function)                           cache:242
db                                             cache:211
ab                                             cache:212
(anonymous function)                           cache:209


Original issue reported on code.google.com by jmara...@google.com on 25 Nov 2014 at 10:21

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

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.

Original comment by jmara...@google.com on 25 Nov 2014 at 11:09

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 26 Nov 2014 at 3:12

  • Changed state: Started
@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

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.

Original comment by jmara...@google.com on 26 Nov 2014 at 5:00

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

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.

Original comment by dmit...@hyperlinksmedia.com on 26 Nov 2014 at 5:30

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

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?


Original comment by jmara...@google.com on 26 Nov 2014 at 9:28

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

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?

Original comment by jmara...@google.com on 26 Nov 2014 at 9:48

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

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.

Original comment by j...@google.com on 1 Dec 2014 at 9:24

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

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

Original comment by j...@google.com on 2 Dec 2014 at 6:27

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 2 Dec 2014 at 6:32

  • Added labels: Milestone-v32, release-note
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment