Toggling customizer controls based on another control does not work anymore in 4.3

[maimairel]

Hi,

Since update v4.3, the toggling of customizer controls based on another customizer control does not work anymore. It works, but gets hidden immediately after the customizer finished loading.

I checked the core code, and nothing has changed so it must be something else. It's this code that I'm talking about, in wp-admin/js/customize-controls.js

// Control visibility for default controls
$.each({
	'background_image': {
		controls: [ 'background_repeat', 'background_position_x', 'background_attachment' ],
		callback: function( to ) { return !! to; }
	},
	'show_on_front': {
		controls: [ 'page_on_front', 'page_for_posts' ],
		callback: function( to ) { return 'page' === to; }
	},
	'header_textcolor': {
		controls: [ 'header_textcolor' ],
		callback: function( to ) { return 'blank' !== to; }
	}
}, function( settingId, o ) {
	api( settingId, function( setting ) {
		$.each( o.controls, function( i, controlId ) {
			api.control( controlId, function( control ) {
				var visibility = function( to ) {
					control.container.toggle( o.callback( to ) );
				};

				visibility( setting.get() );
				setting.bind( visibility );
			});
		});
	});
});

Thank you :)

[netweb]

Adding the chat note by @ celloexpressions in Slack ​https://wordpress.slack.com/archives/core/p1440004003001718

"#33420, #33428 and #33434 are all duplicates. Testing, looks like the code that toggles those is conflicting with their active states. Best solution is probably to do #29948, but we likely need to figure something else out for 4.3.1. Looks like changing static front page also re-calculates the top position of the section (incorrectly),”

Related: #33420 and #33434

Possible Duplicate: #29948

[nikeo]

This bug can be reproduced in TwentyFifteen when accessing the Static Front Page customizer section.
=> The visibility of the controls page_for_posts and page_on_front depends upon the show_on_front setting value.
Since 4.3, the 2 dependant controls are always visible in the two following cases (as far as I understand) :

• first customizer load
• when the preview is refreshed (because the construct.activate() #2631 method is fired when api.previewer.preview is 'ready'

The bug can be fixed in those two cases by adding a check on the args param of the control.onChangeActive(active, args) method to see if the control is unchanged or not.

patch coming

[westonruter]

#33518 was marked as a duplicate.

[westonruter]

#33434 was marked as a duplicate.

[westonruter]

#33420 was marked as a duplicate.

[westonruter]

I've identified that the regression was introduced in [33610] to fix #33220.

Specifically, the regression was caused by this change:

src/wp-admin/js/customize-controls.js

@@ -2603 +2624 @@
                                 _( constructs ).each( function ( activeConstructs, type ) {
                                         api[ type ].each( function ( construct, id ) {
                                                 var active = !! ( activeConstructs && activeConstructs[ id ] );
-                                                construct.active( active );
+                                                if ( active ) {
+                                                        construct.activate();
+                                                } else {
+                                                        construct.deactivate();
+                                                }
                                         } );
                                 } );
                         } );

Prior to this change, calling construct.active( active ) would be a no-op if the construct.active.get() already was already equal to the new active variable. But now that we are explicitly calling construct.activate() and construct.deactivate(), we have to explicitly check whether the state is unchanged.

[westonruter]

Ensure that any completeCallback gets called

[nikeo]

@westonruter ah yes the completeCallback() must always be fired thanks

[westonruter]

@maimairel Can you confirm the latest patch fixes your issue?

[westonruter]

#33538 was marked as a duplicate.

[westonruter]

Additional change: ​https://github.com/xwp/wordpress-develop/commit/6f68997198b08fd44bd0b2481e08c8216914ff13

[westonruter]

I realized the unchanged check also needs to be included in Container.onChangeActive to do the same thing for sections and panels. See 33428.3.diff​.

Incidentally, this also resolves #33494.

[westonruter]

In 33754:

Customizer: Ensure persistence of unchanged active state for controls, sections, and panels.

Props nikeo, westonruter.
Fixes #33428 for trunk.
See also #33494.

[westonruter]

Re-opening for 4.3.1: [33754] needs to be cherry-picked into the 4.3 branch when it is open for business.

[westonruter]

#33494 was marked as a duplicate.

[westonruter]

In 33941:

Customizer: Ensure persistence of unchanged active state for controls, sections, and panels.

Cherry-picks [33754] onto 4.3 branch.
Props nikeo, westonruter.
Fixes #33428 for 4.3.
See also #33494.