Customizer Save race condition when attempting to publish too soon after updating widget form fields with multiple edits

[westonruter]

On a slow connection or if a widget update callback takes any amount of processing time complete, multiple edits to one or more form fields will have multiple simultaneous update_widget Ajax requests open at a time. The last one to return would have the winning instance data to supply for the widget form: a race condition. Before an update widget request is kicked off, any previous request should be aborted so that only the last user-submitted data is used in the form instance.

Additionally, when invoking the Customizer Save functionality, it needs to hold off on gathering up the {{customized}} data to POST to the server until the {{processing}} state is cleared-out; right now it is incorrectly obtaining the data to send before any widgets have finished processing to get their settings from the server over Ajax.

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/75

[westonruter]

In 31501.diff​:

• Abort a previous updateWidget request when starting a new one
• Defer gathering customized data until processing state is properly zeroed-out

Example widget that illustrates current problem: ​https://gist.github.com/westonruter/3b472e1491be0bb6bfb4
Try updating the two fields back and forth quickly, pause a moment to see them appear in the preview, then type some more and then immediately hit Save & Publish. The data that ends up getting saved is consistently not the last data that was entered.

[usability.idealist]

oha. this could be one of the reasons why we've been experiencing "Customizer Preview works, but is not saving anything" issue with CC2 lately.

We've got 150+ settings, so that might indeed a possibility.

cu, w0lf.

[ocean90]

In 31706:

Customizer: Prevent a race condition when attempting to publish too soon after updating widget form fields with multiple edits.

props westonruter.
fixes #31501.

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/77

[westonruter]

I found a defect that the patch for this ticket helped highlight, due to the new jqxhr.abort() call, but it would have happened before as well in case of a network error. The problem is when adding a new widget, the processing state will get incremented to prevent the Customizer from saving the settings before the server returns with the sanitized setting. If you immediately start making changes to the newly added widget, then this will cause the jqshr.abort() to fire which then results in the jqxhr.fail() callback to fire in the updateWidget method. The updateWidget method used when adding a new widget currently has a complete callback that throws any jqxhr error. If this happens, as in the case of abort, then the processing decrement in the jqxhr.always() callback will fail to run, and the processing state will get stuck at a non-zero number. The result is that the settings can then never be saved.

The only reason why I added the throw of the error was to show something on the console.

So I suggest removing it in 31501.2.diff​ to prevent the jqxhr.always() callback from indeed not always getting called.

[ocean90]

In 31816:

Customizer: Remove a throw error call which prevents further actions, like jqxhr.always().

props westonruter.
fixes #31501.