Lost pending customizer settings after theme change

[kirasong]

If you make a change in the customizer, don't publish the change, then choose a different theme, your browser prompts you as to whether you want to leave the current page or not.

If you say no, the customizer hangs.
If you say yes, you lose your settings.

Video example to be attached shortly.

[kirasong]

This is a problem in WordPress 4.4.2 (so not a regression in 4.5).
I haven't dug back to find out if it's been a problem since theme switching.

[celloexpressions]

This is unfortunately expected behavior. Users need to save their changes before switching themes, and because a theme switch does in fact do a page load, if they "leave" by switching themes they'll lose their changes. I believe that customizer transactions and the ability to have draft changes could eventually lead to a better solution here, although the page load when switching themes would be very difficult to eliminate.

[westonruter]

@celloexpressions yes the loss of dirty settings is expected. However, what about the hanging behavior? I haven't experienced that before.

[kirasong]

The biggest trouble here is clicking on "Stay on this page" doesn't go back to where the user was previously, and just hangs.

If it's by design, then thinking we should warn the user and allow canceling the choice (or at least fix this issue where clicking "stay" does not "go/hang".

[celloexpressions]

The theme switcher uses the customize-loader script, which gives the illusion that there is no page load. However, what really happens is we fade in a full-screen loading indicator while waiting for a response from the serve to navigate to the new URL. However, when there are dirty settings, it has to confirm() (?) first. There isn't (or wasn't, at least) to know when a true/false value is returned from the confirm call, so we have to hide the loading indicator as soon as the confirm window is closed so that the user isn't stuck with a loading indicator preventing them from getting "back" to the customizer so that they can save there changes. When you do chose to lose changes, it still hides the loader, giving the impression of it hanging when really it's just doing the same thing it does when there are no dirty settings, but without the loading indicator.

Not a great UX, so hopefully we'll be able to improve on it at some point.

(to clarify, "stay on this page" is the previous theme, where settings are dirty; "leave" is go to the new theme, since you don't actually trigger the link until it's the last )

[westonruter]

I've just implemented the fix for this in working on #30937 (customize transactions changesets). See: ​https://github.com/xwp/wordpress-develop/pull/161/commits/8b8e0256de199fc18d37fb4866df1cff5730c925#diff-58dfe22165ffd9650354f7bdd51002ecR3013

See full PR: ​https://github.com/xwp/wordpress-develop/pull/161

[westonruter]

This has been implemented in the patch for #30937.

Please test: grunt patch:https://github.com/xwp/wordpress-develop/pull/161

As noted there: now when you make a change to a theme_mod in theme A (like change background color to red) and then switch to another theme B and activate it instead, the next time you open theme A in the customizer for live preview the changes you made previously will be applied as your customizer state (the color will be background color will be red again). This is implementing ​feedback from @jorbin:

With this feature I would strongly encourage thinking in terms of user flow.

For example, "As a user, when I am live previewing and making changes to the twentyseventeen theme and then switch to live previewing the twentyten theme, I expect the customizations I made to twentyseventeen to be there the next time I live preview it"

[westonruter]

In 38810:

Customize: Implement customized state persistence with changesets.

Includes infrastructure developed in the Customize Snapshots feature plugin.

See ​https://make.wordpress.org/core/2016/10/12/customize-changesets-technical-design-decisions/

Props westonruter, valendesigns, utkarshpatel, stubgo, lgedeon, ocean90, ryankienstra, mihai2u, dlh, aaroncampbell, jonathanbardo, jorbin.
See #28721.
See #31089.
Fixes #30937.
Fixes #31517.
Fixes #30028.
Fixes #23225.
Fixes #34142.
Fixes #36485.