#42502 closed defect (bug) (fixed)
Customize: Autosave revision not dismissed after first change
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.9 | Priority: | normal |
Severity: | normal | Version: | 4.9 |
Component: | Customize | Keywords: | has-patch commit dev-reviewed |
Focuses: | Cc: |
Description
After having saved a draft of a changeset, any changes you make after this will get stored in an autosave revision for that changeset. If you reload the Customizer without saving the changeset again, then when the Customizer is loaded a notification will appear for whether or not to restore the autosave revision. If the user clicks the dismiss button, then an Ajax request is opened to dismiss the autosave to prevent it from being prompted again and the notification is removed. Additionally, the notification is removed if any change is subsequently made, but the autosave revision dismissal request is not opened in this case.
See code here: https://github.com/WordPress/wordpress-develop/blob/58fad5b/src/wp-admin/js/customize-controls.js#L8297-L8344
The lack of autosave revision dismissal at the point where a change
happens has a negative consequence: an Ajax request in the preview will include the customize_autosaved
parameter (since the autosaving
message was received, see #42475) but since the autosave revision hasn't been dismissed then it will get loaded in the request, and cause a mismatch between the changeset state in the user's browser and the changeset data that is used for previewing.
The easiest way to replicate the problem is:
- Add 5 nav menu items
- Save draft
- Put the last item as the first and the first item as the last.
- Reload, giving a second before confirming to give autosave a chance.
- Notice the autosave notification.
- Move the second nav menu item after the third nav menu item.
- Notice the autosave notification go away.
- BUG: Notice that even though you only moved the second nav menu item after the third, the first and last nav menu items _also_ switched places. This is because the autosave revision was incorrectly restored since it hasn't been dismissed yet.
Video: https://youtu.be/dnu8Lw8Pr14
The immediate fix is just to make sure the revision dismissal request happens both when dismissing the notification explicitly and when dismissal happens implicitly as result changing an item.
In 4.9.1 I'd like to revisit the autosaving logic to harden how the autosaved state is passed around.
Attachments (2)
Change History (12)
This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.
7 years ago
#5
@
7 years ago
Here is another video, with narration, that demonstrates the issue that the patch is intended to fix: https://youtu.be/odlb-h0WPNw
The patch makes sure that the autosave revision gets dismissed whether the notification is dismissed explicitly (with a click on the notifications X button) or implicitly (by making any change in a control).
#6
@
7 years ago
Here is another video, with narration, that demonstrates the issue that the patch is intended to fix: https://youtu.be/odlb-h0WPNw
The patch makes sure that the autosave revision gets dismissed whether the notification is dismissed explicitly (with a click on the notifications X button) or implicitly (by making any change in a control).
#7
@
7 years ago
- Keywords dev-feedback removed
I was able to reproduce the problem, and after applying 42502.diff the problem no longer appears.
For other testers: The problem doesn't manifest itself in the customizer controls, only in the preview pane, resulting in correctly ordered menu items in the customizer control pane but incorrectly ordered menu items in the preview.
@
7 years ago
Prevent a second unnecessary request to dismiss autosave revision after explicit dismissal (via X click) is followed by implicit dismissal (via change event)
Able to replicate the bug in trunk.
Testing your patch, however, the issue persists. :/ I'm still seeing the menu items switch places.