Customizer: First autosave after publish moves you out of the "Block Settings" area

[mreishus]

Inside the customizer, I can open the widget section and edit blocks using gutenberg. For any block, I'm able to use the 3 dots menu and choose "Show more settings" to access Gutenberg's "Block Settings" area. Here, I may want to make several changes, like changing the text color, the background color, and the font size. However, in some circumstances, after making a single change, I'm taken out of the "Block Settings" area for seemingly no reason.

I've found that certain plugins and themes can make this happen on more occasions (for example, on every autosave instead of only the first), but I have steps to recreate on a completely new, out of the box install using wp-env. As of now, this is 5.9-alpha-51726. My gutenberg repo is on da052f066b0f from 2021-09-02.

Steps to reproduce

• Cloned ​https://github.com/WordPress/gutenberg
• Cd into it and wp-env destroy && wp-env start to create a clean WP
• Visit ​http://localhost:8888/wp-admin/ and login with admin:password
• Appearance -> Customize in sidebar menu
• Widgets in sidebar menu
• Plus sign button to create a new block, select paragraph block, type "hello" into it
• Click on the block you just added to see the floating gutenberg bar
• Click the three dots menu then select "Show More Settings"
• Change the text color
• Click 'publish'
• Click on the block you just added to see the floating gutenberg bar
• Click the three dots menu then select "Show More Settings"
• Change the text color
• Expect to see: Remain in the "Block Settings" area
• Actually see: You are taken out of the block settings area

Video: ​https://user-images.githubusercontent.com/937354/131900785-c9f3e678-349d-43fa-9862-ba712740ed03.mp4

This has something to do with Autosave in conjunction with ​this code from the customizer. I remove the line api.state( 'saved' ).bind( updateSectionActive );, the bug no longer happens.

I am confused why it happens sometimes and other times it does not. However, my steps to reproduce should always work. The reason this is an issue is when using blocks with complicated interfaces in this section, it becomes very difficult to use in the customizer, since potentially every change can bring you back and force you to choose "... -> Show More Settings" before doing more work.

[mreishus]

I've determined this is a side effect of the publish button moving from OFF to ON. That's why I need to publish in my steps to reproduce (to turn it off), then I make a change (which turns it on).
Untested hypothesis: One of the various onChangeActive handlers is causing this.

--

When the current theme does not support 'customize-selective-refresh-widgets', the undesirable behavior happens more often (after every change, not just every change when the publish button is in the off state).

[mreishus]

When the customizer reflows, each section reinits and figures out if it should be active. It uses an incoming "active" variable but also wants to make sure the area "is contextually active".
​https://github.com/WordPress/wordpress-develop/blob/40edc2addb5284804e698beda487206f8dd70992/src/js/_enqueues/wp/customize/controls.js#L999
In the case of the block settings section, it thinks that it is active, but the is contextually active returns false, so it becomes inactive and collapses.
The default definition of isContextuallyActive for a section, looks for controls in that section, then checks to make sure at least one is active.
​https://github.com/WordPress/wordpress-develop/blob/40edc2addb5284804e698beda487206f8dd70992/src/js/_enqueues/wp/customize/controls.js#L1559-L1569
In the case of the block settings, it doesn't find any controls, so this section fails. This is probably because the block settings section is coming from Gutenberg, and this is a missing part of the integration; it doesn't recognize any of the controls in Gutenberg.
so the step forward is to find out how to override isContextuallyActive for the block controls section, which might mean a PR to Gutenberg; it's possibly being added somewhere in the 'package/customize-widgets' or 'package/edit-widgets' directories in G.

[mreishus]

Created Gutenberg PR ​https://github.com/WordPress/gutenberg/pull/34543

[audrasjb]

Hello, thanks for reporting this ticket. It appears this issue wasn't introduced in WP 5.9, so I'm removing the trunk version from the ticket.