[wp-trac] [WordPress Trac] #27491: Widget Customizer: Dynamically-created inputs cause from to replace itself without event to trigger re-initailization

[WordPress Trac]

#27491: Widget Customizer: Dynamically-created inputs cause from to replace itself
without event to trigger re-initailization
--------------------------+-------------------
 Reporter:  westonruter   |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  3.9
Component:  Widgets       |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:  javascript    |
--------------------------+-------------------
 In the customizer, with every input/change event, a widget's fields get
 submitted via Ajax to the widget's `update` callback to obtain the updated
 widget instance (to pass along to the preview), and as part of this the
 widget's `form` callback is also executed and the new widget form is
 returned being populated with the sanitized instance. On the widgets admin
 page, there is a Save button which causes the widget form to get
 completely replaced with this sanitized widget form. But since in the
 customizer the form gets submitted with each user input, it cannot replace
 the form or else the user would continually lose their inputs if they
 enter them faster than the Ajax response returns.

 When the Ajax response returns with the newly-sanitized widget form, we
 compare the existing widget form already loaded with the new widget form
 and check to verify that all of the same field elements are there, as if
 they are, then we can iterate over the original inputs in parallel with
 the sanitize inputs, and copy the state over from the sanitized input to
 the original input if sanitization caused it to be different (and if the
 user is not still focused in that field).

 If, however, it finds that the input fields in the sanitized form do not
 match the current widget input fields, then the entire form is currently
 getting replaced (as it does on the widgets admin page).

 With this background in mind: if a widget dynamically creates fields using
 JavaScript when the form is first rendered, any user inputs in that form
 will likely cause a field mismatch in the response, and the form will get
 replaced. Besides the poor experience of the form getting replaced
 unexpectedly, this also will result in any dynamically-generated fields
 getting lost because there is currently no event triggered when a widget
 form is updated (see  #19675: Add a jQuery triggers to the widget save
 action).

 There are two suggestions I have for how the above problems can be solved:

 1) In the customizer, if there is a field mismatch between a sanitized
 form and the existing form, instead of replacing the form as on the
 widgets admin page, we should stop the live field updates and make the
 Apply button re-appear so that when this button is pressed, the form
 fields get disabled until the form is replaced with the new sanitized
 form.

 2) We need to trigger an event when the widget form is updated so that any
 dynamically-generated fields can be re-initialized. Again, see #19675.

 Also reported at:
 http://wordpress.org/support/topic/initialise-javascript-on-add-save-
 widget?replies=3
 http://wordpress.stackexchange.com/questions/138355/using-javascript-on-
 the-new-widget-preview-customizer-page

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27491>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform