Theme Customizer Goes Bonkers on Frame Buster

[miqrogroove]

When I activate an older theme of my own that does not support the new features, and click Customize, it brings up a left-side menu column only, with no preview on the right, and continuously auto-refreshes the page (it makes Chrome repeatedly display the "X" stop button) until I close it.

Tested customizing "WordPress Classic" theme in Firefox 15 and Chrome 21, could not reproduce.

Just a thought, but my theme has a frame busting script in the header. Could that cause this behavior?

Confirmed. This problem goes away as soon as I delete the frame buster from header.php. Updating ticket title.

I'm not sure there's much we'll be able to do here, If JS in the theme attempts to framebust then there's no way that the customizer can possibly work (and it's not exactly easy to detect beforehand).

In this case, the theme would probably have to disable either the framebusting code for preview requests, or turn the customizer off completely.

Is there already a secure method for detecting the preview requests from within header.php? And are the previews accessible to admins only? If so, then I'll say this is just a bug in the theme.

This would occur, I imagine, using the old thickbox preview from pre-3.4. If so, then the check would be the same: defined( 'IFRAME_REQUEST' ).

so... I think you meant to try this, but it didn't work..

<?php if ( !defined( 'IFRAME_REQUEST' ) ) { ?>
 <!-- bust frames here -->
<?php } ?>

Pretty sure IFRAME_REQUEST is only set for wp-admin related core iframe pages/requests. In this case, you'd be after is_preview() (A WP_Query offered functionality)

I don't think that's hooked up. I can see where it's initialized in query.php, but it always returns false.

Wait, doesn't the query run *after* header.php?

Nevermind, I was thinking of "the loop".. which is different. Anyway, let's leave this ticket open until there's working mechanism for preview detection.

I don't think that's hooked up. I can see where it's initialized in query.php, but it always returns false.

I'm feeling a bit silly this morning, is_preview() is for POST previews, not for blog previews.. oops.

I think the best solution is to perform origin checking in JS rather than trying to fix it in PHP. This works to accomplish frame busting while remaining compatible with WP:

if (window != top) {
    if (window.parent.location.host != window.location.host) {
        top.location = document.location;
    }
}