[wp-trac] [WordPress Trac] #23225: Customizer is Incompatible with jQuery UI Tabs.

[WordPress Trac]

#23225: Customizer is Incompatible with jQuery UI Tabs.
-------------------------------------+------------------
 Reporter:  mfields                  |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  4.1
Component:  Customize                |     Version:  3.4
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:
-------------------------------------+------------------
Changes (by westonruter):

 * milestone:  Awaiting Review => 4.1


Comment:

 In [attachment:class-wp-customize-manager.php.patch], I'm seeing that
 `document.location.href` is not returning the URL of the Customizer
 preview even though a `base[href]` is being set (e.g. I'm seeing
 `http://src.wordpress-develop.dev/wp-admin/customize.php` instead of
 `http://src.wordpress-develop.dev/`). This is probably due to the fact
 that the preview `iframe` is getting populated dynamically via
 a`document.write()` call and not by actually being navigated to, so the
 preview window is inheriting the parent window's `document.location.href`.

 So It seems way for preview to determine its own URL is to instead look at
 the `base` DOM element's `href` property. In [attachment:23225.2.patch]
 I've made this change. It's also now using jQuery to update the link
 `href` attributes, and it is outputting a `base[href]` containing the
 `REQUEST_URI` not just the `home`, to address your concern @helen.

 Nevertheless, the Customizer hasn't been taking into account that a theme
 may be outputting a `base` element of its own. Also, if the Customizer
 preview dynamically adds new `#` links they're not going to be rewritten
 to have the right `base`.

 Patches for this ticket are added to a PR on GitHub:
 https://github.com/xwpco/wordpress-develop/pull/30

 As an aside, all of this leads me to think that the current method for
 populating the Customizer preview `iframe` introduces fundamental
 limitations, and some things that just aren't going to work in the way it
 is currently designed. It would be better if we could use the `iframe` in
 a more traditional way, setting the `src` attribute to the URL being
 previewed (doing a GET request) and not doing `document.write()` on an
 `about:blank` iframe (writing the response to an Ajax `POST`); this would
 require an alternative back-channel for passing the settings data to the
 preview.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/23225#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform