[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:  4.2
Component:  Customize    |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  javascript
-------------------------+-------------------------
Changes (by westonruter):

 * milestone:  Awaiting Review => 4.2


Old description:

> 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.

New description:

 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.

 Fixes #23225

--

Comment:

 Moving this to 4.2 since the issue would be resolved by #30937.

 The new communications channel mentioned in the description is the
 “Customize transactions” proposed in #30937. Instead of the current Ajax
 POST + `document.write()` approach for populating the Customizer preview,
 the patch developed for that ticket implements the loading of the preview
 iframe with a normal GET request for the desired URL with a transaction ID
 query argument added.

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