Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#21854 closed defect (bug) (wontfix)

Theme Customizer Goes Bonkers on Frame Buster

Reported by: miqrogroove Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.4.2
Component: Customize Keywords:
Focuses: Cc:


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.

Change History (15)

comment:1 @SergeyBiryukov3 years ago

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

comment:2 @miqrogroove3 years ago

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

comment:3 @miqrogroove3 years ago

  • Summary changed from Theme Customizer Goes Bonkers on Old Themes to Theme Customizer Goes Bonkers on Frame Buster

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

comment:4 @SergeyBiryukov3 years ago

  • Component changed from Themes to Appearance

comment:5 @dd323 years ago

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.

comment:6 @miqrogroove3 years ago

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.

comment:7 @nacin3 years ago

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' ).

comment:8 @miqrogroove3 years ago

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

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

comment:9 @dd323 years ago

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)

comment:10 @miqrogroove3 years ago

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

comment:11 @miqrogroove3 years ago

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

comment:12 @miqrogroove3 years ago

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.

comment:13 @dd323 years ago

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.

comment:14 @miqrogroove3 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

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;

comment:15 @helenyhou3 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.