[wp-trac] [WordPress Trac] #30028: Load Customizer preview iframe with natural URL

[WordPress Trac]

#30028: Load Customizer preview iframe with natural URL
-------------------------+-----------------------------
 Reporter:  westonruter  |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Customize    |    Version:
 Severity:  normal       |   Keywords:  needs-patch
  Focuses:  javascript   |
-------------------------+-----------------------------
 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.

 To implement this (as discussed on
 [https://core.trac.wordpress.org/ticket/23225#comment:21 #23225:22]) we'll
 need to introduce a new communications channel to push Customizer settings
 changes into the preview when a `refresh` transport is invoked. Instead of
 sending the settings with `POST` request to load the page, we'll need to
 send settings changes into a transient which the Customizer preview can
 read from when loading a page via a regular `GET` request. A side effect
 of this may be that we need to disallow a user from opening the Customizer
 in multiple windows, since the Customizer preview won't know which
 Customizer pane it is associated with.

 Another gotcha here, perhaps another reason why `document.write()` was
 chosen for populating a blank iframe, is maintaining the scroll position
 when a refresh happens. Doing a `location.reload()` in the preview window
 may not have a seamless preservation of the scroll position. We may need
 to make sure the Customizer preview gets sent back with output buffering
 so that the entire document is sent all at once so that incremental
 rendering does not interfere with the prior scroll position.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30028>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform