Make WordPress Core

Opened 7 years ago

Last modified 3 years ago

#38954 new defect (bug)

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

Reported by: celloexpressions's profile celloexpressions Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.6.1
Component: Customize Keywords: needs-patch
Focuses: Cc:

Description

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.

Attachments (3)

debounced-nav-menu-item-full-refreshes.mov (8.2 MB) - added by westonruter 7 years ago.
38954.gif (232.2 KB) - added by celloexpressions 7 years ago.
Requests sent for each keystroke in Firefox.
38954-selective-refresh.gif (1.2 MB) - added by celloexpressions 7 years ago.
On a menu with selective refresh, numerous requests are sent and aborted.

Change History (13)

#1 @westonruter
7 years ago

  • Keywords reporter-feedback added

@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
7 years ago

Requests sent for each keystroke in Firefox.

@celloexpressions
7 years ago

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

#2 @celloexpressions
7 years ago

  • Keywords reporter-feedback removed

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.

#3 @westonruter
7 years ago

  • Keywords reporter-feedback added; needs-patch removed

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

#4 @celloexpressions
7 years ago

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.

#5 @westonruter
7 years ago

  • Milestone changed from Future Release to 4.8

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.

#6 @westonruter
7 years ago

  • Keywords needs-patch added; reporter-feedback removed
  • Summary changed from Customize Menus: menu item property previewing is not debounced to Customizer: Increase preview refreshBuffer (perhaps with decay) when making rapid changes such as via text inputs

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.

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


7 years ago

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


7 years ago

#9 @obenland
7 years ago

  • Milestone changed from 4.8 to Future Release

#10 @celloexpressions
3 years ago

#47784 was marked as a duplicate.

Note: See TracTickets for help on using tickets.