| 1 | | Currently the Customizer preview is populated by doing an Ajax `POST` request to a the previewed URL and then the Ajax response is written to an `iframe` which has an `about:blank`. This works well to make sure that the change settings get passed along to the Customizer for the refresh, but there are some unintended side effects. For one, the `location.href` of the window in the Customizer preview reflects the location of the parent window, not the location of the URL being previewed. This breaks things like jQuery UI (#23225) when it checks if links are in-page targets. Other aspects of the Customizer preview can be improved if the natural URL is loaded instead of using Ajax, namely the navigation within the preview can be much more robust without needing to implement hacks for catching clicks on link elements to route the URL change up to the Customizer; this will also fix #20714, allowing forms to be interacted with in the Customizer as expected. |
| | 1 | Currently the Customizer preview is populated by doing an Ajax `POST` request to a the previewed URL and then the Ajax response is written to an `iframe` which has an `about:blank`. This works well to make sure that the change settings get passed along to the Customizer for the refresh, but there are some unintended side effects. For one, the `location.href` of the window in the Customizer preview reflects the location of the parent window, not the location of the URL being previewed. This breaks things like jQuery UI (#23225) when it checks if links are in-page targets. Other aspects of the Customizer preview can be improved if the natural URL is loaded instead of using Ajax, namely the navigation within the preview can be much more robust without needing to implement hacks for catching clicks on link elements to route the URL change up to the Customizer; this will also fix #20714, allowing forms to be interacted with in the Customizer as expected. Lastly, it may resolve #35824 where SVG images sometimes currently fail to render in the preview. |