[wp-trac] [WordPress Trac] #38865: Customize: Setting validation error messages can fail to clear if newly-supplied valid value matches previously-valid value stored in changeset

[WordPress Trac]

#38865: Customize: Setting validation error messages can fail to clear if newly-
supplied valid value matches previously-valid value stored in changeset
--------------------------+-----------------
 Reporter:  westonruter   |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  4.7
Component:  Customize     |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------
 In #38705 a change was made to the
 `WP_Customize_Manager::save_changeset_post()` method to skip validating
 any incoming dirty setting values that are equal to values that have
 already been written to the changeset. This was done to prevent changes
 from one user to be inadvertently overridden by a second user, thus either
 causing the `user_id` to be changed or worse for the setting change to be
 rejected since the second user may not have the required `capability`.  A
 problem with this change was discovered in which supplying the same valid
 value was previously supplied (the value which was stored in the
 changeset) gets skipped and so the validation error never gets cleared.

 Consider a `setting` which allows values 1-4. Given a control for this
 setting, let the user supply the value 4, and thus 4 is written into the
 changeset. Now, if a user supplies an invalid value of 5 and then preview
 then refreshes and communicates the `setting_invalidities` to the parent
 window, and the control then gets the error notification. Now, if the user
 then re-supplies the value of 4 ''and'' then immediately clicks into the
 preview, a changeset update request will happen since the customizer
 window lost focus. The `WP_Customize_Manager::save_changeset_post()`
 method sees that this incoming value is the same as is currently in the
 snapshot, and so it is skipped, the result of which is that the valid
 setting flag is not included among the `setting_validities` in the
 response, and so the JS response handler fails to clear the error
 notification. Likewise, since the changeset update request happened
 immediately, the subsequent full refresh or selective refresh of the
 preview will not have any dirty settings to preview and so it will simply
 load the `iframe` with the natural URL with the `customize_changeset_uuid`
 query param (as opposed to doing a form `POST` into an `about:blank`
 preview window), also resulting in an empty `setting_validities`.

 The bug would likely not be experienced frequently by users, but when it
 does happen, it is very confusing.

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