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)

#1 @SergeyBiryukov
3 years ago

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

#2 @miqrogroove
3 years ago

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

#3 @miqrogroove
3 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.

#4 @SergeyBiryukov
3 years ago

  • Component changed from Themes to Appearance

#5 @dd32
3 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.

#6 @miqrogroove
3 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.

#7 @nacin
3 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' ).

#8 @miqrogroove
3 years ago

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

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

#9 @dd32
3 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)

#10 @miqrogroove
3 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.

#11 @miqrogroove
3 years ago

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

#12 @miqrogroove
3 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.

#13 @dd32
3 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.

#14 @miqrogroove
3 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;

#15 @helenyhou
3 years ago

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