Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#37032 closed defect (bug) (fixed)

Guard against infinite reload when setting change causes premature selective refresh

Reported by: westonruter Owned by: westonruter
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.5
Component: Customize Keywords: has-patch needs-testing
Focuses: Cc:


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

Attachments (3)

37032.1.diff (1.0 KB) - added by westonruter 5 years ago.
37032.2.diff (2.4 KB) - added by westonruter 4 years ago.
37032.3.diff (2.4 KB) - added by westonruter 4 years ago.

Download all attachments as: .zip

Change History (18)

5 years ago

#1 @westonruter
5 years ago

  • Keywords has-patch added
  • Owner set to westonruter
  • Status changed from new to accepted

#2 @westonruter
5 years ago

  • Keywords needs-testing added

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.

#3 @westonruter
5 years ago

  • Milestone changed from 4.6 to Future Release

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.

4 years ago

#5 @westonruter
4 years ago

  • Keywords needs-patch added; has-patch needs-testing removed
  • Milestone changed from Future Release to 4.7

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.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.

4 years ago

This ticket was mentioned in Slack in #core-themes by celloexpressions. View the logs.

4 years ago

#8 @ahortin
4 years ago

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


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.

This ticket was mentioned in Slack in #core by westonruter. View the logs.

4 years ago

4 years ago

#10 @westonruter
4 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

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

Last edited 4 years ago by westonruter (previous) (diff)

4 years ago

#11 @westonruter
4 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#12 @westonruter
4 years ago

#38612 was marked as a duplicate.

#13 @ahortin
4 years ago

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

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.

4 years ago

#15 @westonruter
4 years ago

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.

Note: See TracTickets for help on using tickets.