Group block overrides Navigation Link hover color in the editor

[talldan]

Description

In the editor, group block link hover colors can override the navigation block's hover color. This is an inconsistency given the way the frontend works and regular link colors work.

This culprit seems to be this style, which has high specificity due to the :hover pseudoselector:

.editor-styles-wrapper .wp-elements-129 a:hover {
    color: var(--wp--preset--color--accent-3);
}

So it overrides the blocks styles for the navigation block that try to prevent this:

.wp-block-navigation .wp-block-navigation-item__content.wp-block-navigation-item__content {
    color: inherit;
}

Note, there seems to be an e2e test that is supposed to catch this regression:

gutenberg/test/e2e/specs/editor/blocks/navigation-colors.spec.js

Lines 131 to 185 in fced091

	test( 'Navigation text does not inherit the link color from the theme/group', async ( {
	page,
	editor,
	colorControl,
	} ) => {
	// Wrap the nav block inside a group block.
	await page
	.getByRole( 'toolbar', { name: 'Block tools' } )
	.getByRole( 'button', { name: 'Options' } )
	.click();
	await page.getByRole( 'menuitem', { name: 'Group' } ).click();
	// In the sidebar inspector we add a link color and link hover color to the group block.
	await editor.openDocumentSettingsSidebar();
	await page.getByRole( 'tab', { name: 'Styles' } ).click();
	await page.getByRole( 'button', { name: 'Color options' } ).click();
	await page
	.getByRole( 'menuitemcheckbox', { name: 'Show Link' } )
	.click();
	await page.getByRole( 'tab', { name: 'Styles' } ).click();
	await page.getByRole( 'button', { name: 'Color Link styles' } ).click();
	// rga(207, 46 ,46) is the color of the "vivid red" color preset.
	await page
	.getByRole( 'option', { name: 'Color: Vivid red' } )
	.click( { force: true } );
	await page.getByRole( 'tab', { name: 'Hover' } ).click();
	// rgb(155, 81, 224) is the color of the "vivid purple" color preset.
	await page
	.getByRole( 'option', { name: 'Color: Vivid purple' } )
	.click( { force: true } );
	// Close the sidebar so our selectors don't accidentally select the sidebar links instead of the editor canvas.
	await page
	.getByRole( 'button', { name: 'Close Settings' } )
	.click( { force: true } );
	await editor.canvas
	.getByRole( 'document', { name: 'Block: Navigation' } )
	.click();
	const expectedNavigationColors = {
	textColor: colorControl.black,
	backgroundColor: colorControl.transparent,
	submenuTextColor: colorControl.black,
	submenuBackgroundColor: colorControl.white,
	};
	await colorControl.testEditorColors( expectedNavigationColors );
	// Check the colors of the links on the frontend.
	const postId = await editor.publishPost();
	await page.goto( `/?p=${ postId }` );
	await colorControl.testFrontendColors( expectedNavigationColors );
	} );

But while it sets group block link hover styles, it doesn't assert that the navigation hover styles are correct.

Step-by-step reproduction instructions

1. Add a group block
2. In the inspector tools for the group block, go to the styles tab and set a noticeable link color and link hover color (you may have to "Show Link" colors in the "Color options" dropdown menu of the color panel)
3. Add a navigation block in the group with some navigation links
4. Observe that the link color set on the group block isn't applied to the navigation block
5. Hover over one of the links (or using the inspector tools enable hover styles on one of the links)
6. Observe that the hover color is applied to the navigation block

Also view the front end of the site and observe that link and link hover colors aren't applied, so this seems to be an inconsistency only in the editor.

Screenshots, screen recording, code snippet

No response

Environment info

Reproduced on WordPress 6.5 & 6.6

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

[carolinan]

I am not sure I understand -colors set on the parent, are intended to override the color on the child, unless the child also has a color set.

[talldan]

@carolinan Sorry, I missed the ping. The main thing is the inconsistency - regular (non-hover) colors and hover colors are working differently.

It's really hard to say how the navigation block is supposed to work, but the e2e tests seems to imply it shouldn't inherit any colors from a wrapping group.