The new blockEditor.useSetting.before filter does not appear to be working with background color

[ndiego]

Description

While testing the new blockEditor.useSetting.before, I found that it doesn't appear to work when trying to disable the color.background setting on blocks. It's quite strange since disabling color.link and color.text work as expected. I'm unsure if this is an isolated issue or hints at a larger bug with this filter, but I will follow up if I find any others.

Step-by-step reproduction instructions

1. In TT3, create a new file called filters.js
2. Enqueue this file using the code below.
3. Add the filter code below to filters.js.
4. Add a Heading block to a new page.
5. Check that text color is disabled, but background color is not.

Screenshots, screen recording, code snippet

In functions.php

function test_block_filters() {
	wp_enqueue_script( 
		'test_block_filters', 
		get_stylesheet_directory_uri() . '/filters.js', 
		array( 'wp-edit-post' ) ,
		wp_get_theme()->get( 'Version' ),
		true
	);
}
add_action( 'enqueue_block_editor_assets', 'test_block_filters' );

In filters.js

wp.hooks.addFilter(
	'blockEditor.useSetting.before',
	'myPlugin/useSetting.before',
	( settingValue, settingName, clientId, blockName ) => {

		// Works.
		if ( blockName === 'core/heading' && settingName === 'color.text' ) {
			return false;
		}

		// Does not work.
		if ( blockName === 'core/heading' && settingName === 'color.background' ) {
			return false;
		}

		return settingValue;
	}
);

Environment info

• WordPress 6.2 RC2

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[ndiego]

cc @ingeniumed @alecgeatches @aaronrobertshaw

I am going to add this to the 6.2 Board for now since this seems to be a bug and is related to a new feature in 6.2, but it's not a blocker.

[t-hamano]

It is a bit complicated, but I think the gradient setting also needs to be completely disabled. The following code will hide the Background Color panel:

wp.hooks.addFilter(
	'blockEditor.useSetting.before',
	'myPlugin/useSetting.before',
	( settingValue, settingName, clientId, blockName ) => {
		if ( blockName === 'core/heading' ) {
			if ( settingName.startsWith( 'color.gradients.' ) ) {
				return [];
			}
			if ( settingName === 'color.background' || settingName === 'color.customGradient' ) {
				return false;
			}
		}
		return settingValue;
	}
);

[ndiego]

Ah thanks @t-hamano! I will do some more testing on this next week, because I’m curious if the same thing happens when disabling background color at the block level in theme.json.

[aaronrobertshaw]

Thanks for the ping @ndiego 👍

As @t-hamano indicated I don't think this is an issue with the blockEditor.useSetting.before filter, it's an unfortunate side effect of how the color block supports were implemented initially.

There are some existing issues for this already including #41293 & #45273.

My suggestion here would be to close this one as a duplicate.

[ndiego]

@aaronrobertshaw yeah, upon further testing, it all looks to be the same situation. I'll make sure to add this callout in the documentation I'm working on. Thanks for the follow-up. 💪

Closing this out as a duplicate of #41293.