Customizer Messenger (postMessage) instead of cross-frame communication

[westonruter]

When the preview window loads, it communicates to the host page to show only the customizer sections for sidebars that were rendered on the page. We're doing this just accessing jQuery in the parent frame and not using postMessage or the Customize Messenger library. I couldn't see quickly how to access the Preview instance to send more message from the window, because it is protected inside a closure.

[westonruter]

We're going to have to rely on this if the preview is in another domain. In customize-controls.js we see api.settings.isCrossDomain and in wp-admin/customize.php we see:

// If the frontend and the admin are served from the same domain, load the
// preview over ssl if the customizer is being loaded over ssl. This avoids
// insecure content warnings. This is not attempted if the admin and frontend
// are on different domains to avoid the case where the frontend doesn't have
// ssl certs. Domain mapping plugins can allow other urls in these conditions
// using the customize_allowed_urls filter.

$allowed_urls = array( home_url('/') );
$admin_origin = parse_url( admin_url() );
$home_origin  = parse_url( home_url() );
$cross_domain = ( strtolower( $admin_origin[ 'host' ] ) != strtolower( $home_origin[ 'host' ] ) );

So we need to not directly reference the parent window and the iframe.contentWindow and instead use postMessage.

[westonruter]

Relates to #2 and #5.

[westonruter]

Also reported by @c2itllc on Twitter:

Am I the only one with force admin SSL + WP customizer issues? Multisite, domain mapping bypassed.

Yes, if FORCE_SSL_ADMIN is turned on, then the non-HTTP customizer preview frame would probably fail to be able to cross-frame communicate with the customizer, which would be the HTTPS parent frame. Using postMessage should resolve this.

[westonruter]

I tried forcing the preview frame to be in another domain, but even when it was, I did not have a problem with cross-frame communication. I think because the Ajax response gets written into the iframe, and the remote URL isn't actually loaded into the iframe directly.

[westonruter]

I wonder if postMessage really isn't needed at all by the Customizer, since the preview seems to be able to communicate cross-window to the parent window just fine. Was it initially added because it was thought that the preview iframe could be loading from another domain? Even when this is the case, it seems not to impact cross-frame communication because the Ajax response is written into the iframe, and the cross-domain URL is not directly loaded into the frame (see customize-controls.js). It seems this gets around any cross-domain security issues. I've tried forcing the preview to load the site from another domain, and it still works.

/cc @ocean90