Customizer: Increase preview refreshBuffer (perhaps with decay) when making rapid changes such as via text inputs

[celloexpressions]

Editing menu item fields (label, description, etc.) currently triggers preview refreshes with every keystroke (the Ajax requests are aborted when a subsequent request is triggered with the next keystroke). Usually menus support selective refresh, but that isn't always the case; and regardless, previewing should be debounced to a few hundred ms.

This may have existed at some point, or may have been an oversight in 4.3. Confirmed that the behavior exists on 4.6.1, so not a recent 4.7 regression.

[westonruter]

@celloexpressions I can't seem to be able to reproduce what I think you're describing. See debounced-nav-menu-item-full-refreshes.mov​.

[celloexpressions]

Requests sent for each keystroke in Firefox.

[celloexpressions]

On a menu with selective refresh, numerous requests are sent and aborted.

[celloexpressions]

See the screencast above demonstrating multiple requests being sent with fairly-continuous typing in Firefox, for a menu with a custom walker. The second screencast is for a menu with selective refresh, and here the console shows numerous requests being triggered and then aborted within a few hundred milliseconds. No requests should be sent (and the preview shouldn't start updating) until typing is paused for probably 500 ms, or whatever the core standard is.

I'm not sure why it appears to be working for you.

[westonruter]

@celloexpressions I'm seeing the same expected behavior in Firefox. From your screencast it seems you're entering content slower than 250ms. If you hit the keys more rapidly then you'll see the request deferred. Easy way to check this is to open the dev tools and inspect the label input element for a given nav menu item. Then enter the following JS into your console, where $0 is a reference to the selected element in the dev tools elements panel (both in Chrome's Dev Tools and Firefox's Inspector):

timeoutId = setInterval( function() { jQuery( $0 ).val( Math.random() ).trigger( 'change' ); }, 200 );

The refreshBuffer is 250 milliseconds, so this should result in the debouncing never allowing a request to go through, until you do clearInterval( timeoutId ).

In contrast, if you try an interval greater than 250ms, then you'll see a refresh with each change as you are noticing:

timeoutId = setInterval( function() { jQuery( $0 ).val( Math.random() ).trigger( 'change' ); }, 300 );

The only way to resolve this would be to increase the refreshBuffer to 500ms or maybe 1s. Perhaps as well the refreshBuffer could be made to be somewhat more dynamic, where it variably increases to 1s when typing into a text field whereas it remains 250ms when making a more atomic change, like changing a dropdown selection.

[celloexpressions]

The screencast is 8 fps I think, so hard to tell from there, although I was typing pretty quickly. However, 500ms tends to be the standard in core so if it is 250ms that would need to be increased. There have been numerous "complaints" floating around about triggering refreshes on every keystroke so if there's an illusion of that happening we need to fix that.

[westonruter]

The refreshBuffer has been 250ms ever since the customizer was introduced in 3.4. It's probably being noticed more now since more text inputs are present, such as nav menus and widgets.

[westonruter]

I think what we can do is generally implement a decay-throttled refreshBuffer, so that if you make one text change (e.g. paste in a value) the preview will be updated after 250ms like currently. But then if you make a second update within 1 second of the previous, then the 250ms refreshBuffer could be lengthened to 1 second, and perhaps this delay could keep growing until the user ceases to make a change for X seconds. The logic for how the decay would grow needs to be worked out, but I think this could be a great general-purpose solution both for full- and selective refreshes.

[celloexpressions]

#47784 was marked as a duplicate.