Customizer: Block Widgets: Changing settings causes active section to change

[mreishus]

Steps to reproduce the behavior

1. Visit the customizer of a simple site (Apperance -> Customize)
2. Click on 'Widgets'
3. If applicable to your theme, choose an area like 'Sidebar' or 'Footer'
4. Click inside a block widget, (or add a simple paragraph block if you don't have one and click in it)
5. Click on the 3 dot menu in the floating Gutenberg toolbar
6. Click "Show more settings"
7. Change any of the settings displayed in this sidebar. For example, change the font size, or turn on "Drop Cap."

What I expected to happen

7. The change is made and you stay on the "Show more settings" sidebar section you are on.

What actually happened

8. The change is made and the active sidebar section

Videos

Peek.2021-08-31.14-25-wpcom-behavior-customizer-advanced.mp4

^ Unexpected behavior on .com simple site - After changing setting, the sidebar display returns to the block

Peek.2021-08-31.14-26-core-behavior-customizer-advanced.mp4

^ Expected behavior on core .org only - After changing setting, the sidebar remains on the settings page

Location of bug

I believe this is an interaction between .com and .org code. If these lines of code in .org are commented out, the undesired behavior no longer happens. However, the bug does not happen on a standalone .org site. I believe .com has an autosave plugin which may be causing this behavior. Changing the setting causes this trigger to fire: the api.state( 'saved' ).bind( updateSectionActive );, and updateSectionActive moves the sidebar away from the settings page and to the block you were editing.

Context

Browser / OS version

Is this specific to the applied theme? Which one?

Does this happen on simple or atomic sites or both?

Is there any console output or error text?

Level of impact (Does it block purchases? Does it affect more than just one site?)

Reproducibility (Consistent, Intermittent) Leave empty for consistent.

[mreishus]

This is theme dependent.

• Twentyninteen, twentytwenty, twentytwentyone - Only the first change sends you back to the block
• Independent Publisher 2, Sapor - All changes send you back to the block

Peek.2021-09-01.11-18-jetpack-visibility-dotcom.mp4

^ Independent Publisher 2 example

[mreishus]

I was able to reproduce this using WP.org only. I downloaded the gutenberg repo and ran wp-env destroy && wp-env start, then logged into http://localhost:8888/wp-admin/ with admin:password before recording this video:

Peek.2021-09-02.13-49-wporg-settings-move.mp4

On .org, I needed to publish once before the error happened, and it only happens on the first change.

[mreishus]

Reported on wp.org trac: https://core.trac.wordpress.org/ticket/54063

[mreishus]

The per-theme behavior is dependent upon add_theme_support( 'customize-selective-refresh-widgets' );. When the active theme doesn't' support this, we see you're kicked out of the block settings more often.

• Core using 20s theme: When publish button goes OFF -> ON, you're kicked out of block settings.
• Any theme without customize-selective-refresh-widgets: Also, when publish button goes ON->ON, you're kicked out of block settings

[mreishus]

Here's the code that's running (at least for case 1 in the 2020s)
https://github.com/WordPress/wordpress-develop/blob/40edc2addb5284804e698beda487206f8dd70992/src/js/_enqueues/wp/customize/controls.js#L1148-L1153
active is false, and construct looks to be the block settings section.. so something is explicitly telling this section to deactivate, I'm just not sure what it is yet

[mreishus]

Got a step closer. 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: WordPress/gutenberg#34543

[sixhours]

Since WordPress/gutenberg#34543 has been merged, I'm marking this as closed. :)