Guard against infinite reload when setting change causes premature selective refresh

[westonruter]

If a setting gets set to a value in JS that is different than the sanitized JS-value exported from PHP, then best case there can be an extra refresh for a partial in the preview, and worse case (if the partial has to fallback to full refresh) there can be an infinite reload in the Customizer preview. The reason for the issue is that selective refresh is currently allowing partial refreshes to be triggered before the settings are sync'ed from the pane to the preview. The fix is to just prevent setting changes from causing a refresh until the active message has been sent from the pane to the preview.

Originally reported at ​https://github.com/xwp/wp-customize-posts/pull/163

[westonruter]

One gotcha with this patch is that there might be a race condition where a change is made to a setting between when the preview refreshes and the active message is sent to the preview. In that case, the change wouldn't appear in the preview. Some additional testing would be needed to identify if this race condition is possible.

[westonruter]

I think the approach in 37032.1.diff​ is wrong. In addition to preventing the triggering of selective refresh we would also need to prevent the triggering of JS-based updates. Consider a blogname sanitizer that enforces title-case: the JS-based update will update the site title to be whatever the user entered without that PHP filter. This means that if we prevent the selective refresh but still allow postMessage updates upon refresh, the preview can be invalid. So what we need to do is set the values quietly in the preview so as to prevent triggering the change event _unless_ the setting was modified after the last refresh was initiated. So the sync message should include a list of the newly-changed settings that need to be set with change events triggered.

[ahortin]

I raised this as an issue over on the Alpha/Beta forum yesterday (​https://wordpress.org/support/topic/live-preview-constantly-refreshing-in-customizer/).

I experienced this issue whilst Live Previewing Twenty Seventeen, and when changing to a different menu.

In responding to my ticket, @clorith wanted to know the content of the menu that I changed to. It was actually a blank menu (as can be seen in this pic).

​https://cl.ly/1N1p0E1J3G3X

On a side note, I've since tried performing the same action (changing to this menu again), and I didn't get the constant refreshing.

[westonruter]

@ahortin @clorith Could you give 37032.3.diff​ a test?

[westonruter]

In 39112:

Customize: Prevent syncing unmodified settings from controls into preview to guard against triggering an infinite reload due to selective refresh fallback behavior.

If a value is sanitized in PHP and differs from the JS value in the pane, a change event for the setting is triggered upon refresh. This should be avoided since the value just came from the server as being sanitized. This also fixes periodic issue where selective refresh happens immediately after a full refresh.

Fixes #37032.

[westonruter]

#38612 was marked as a duplicate.

[ahortin]

@westonruter This patch seems to work for me. I haven't been able to replicate the issue again so far. Thanks.

[westonruter]

In 39510:

Customize: Prevent infinite full refresh from occurring when selective refresh falls back for a nav menu that has items excluded from rendering via filtering.

See #37032.
Fixes #38612.