Fix overflow of Highlighted white-space in Code Block

[coderGtm]

What?

Closes #69668

Fixes the highlight issue for the frontend but does not seem to be working for editor.

Why?

Currently, when text within a code block is highlighted and includes extra white space, it can overflow beyond the code box, which is not ideal. While this issue is uncommon, it negatively affects the overall UI experience when it does happen.

How?

The PR introduces a variable called whiteSpaceStyle that determined the value of the white-space property of the component style. It uses the modern break-spaces value to fix the issue on browsers that support this value and uses the older pre-wrap on incompatible browsers.

Testing Instructions

1. Create a new Post
2. Insert a code block with extra white-spaces at the end of 1 line.
3. Highlight the code's background from the Block Controls Toolbar.
4. Verify that the highlight does not overflow the code block in the frontend.

Screenshots

Before	After

Note

This PR is the same as #70301 but since it was based from trunk, there were many issues. Hence this new PR is created for a cleaner workflow.

Thanks

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: coderGtm <gautam23@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: Rishit30G <rishit30g@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mamaduka]

@coderGtm, it looks like prettier is triggering some errors for changes. See - https://github.com/WordPress/gutenberg/pull/77085/changes.

[Mamaduka]

Thanks for creating a new PR, @coderGtm!

I just retested, and this doesn't seem to fix the problem. The support is correctly detected, but RichText ignores styles override and still applies pre-wrap.

The pre-wrap styling is coming from the useDefaultStyle hook, which is triggered later and overrides the custom whiteSpace.

Does this fix work in your testing?

Screenshot

[t-hamano]

The pre-wrap styling is coming from the useDefaultStyle hook, which is triggered later and overrides the custom whiteSpace.

I have confirmed the same behavior. Should we prioritize the style prop?

diff --git a/packages/rich-text/src/hook/use-default-style.js b/packages/rich-text/src/hook/use-default-style.js
index 5d45d027034..f09bd42b783 100644
--- a/packages/rich-text/src/hook/use-default-style.js
+++ b/packages/rich-text/src/hook/use-default-style.js
@@ -30,6 +30,6 @@ export function useDefaultStyle() {
                if ( ! element ) {
                        return;
                }
-               element.style.whiteSpace = whiteSpace;
+               element.style.whiteSpace = element.style.whiteSpace || whiteSpace;
        }, [] );
 }

[t-hamano]

I understand this check is based on #70301 (comment), but since break-sopaces has been supported across all browsers for several years, I believe this check can be removed. What do you think?

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/white-space#browser_compatibility

[Mamaduka]

Good point. The 97% support should be good - https://caniuse.com/?search=white-space.

[coderGtm]

Okay so should I remove it then to keep only break-spaces?

[t-hamano]

Suggested change

	@supports (white-space: break-spaces) {
	white-space: break-spaces;
	}
	white-space: break-spaces;

This can also be simplified

[coderGtm]

Hello @Mamaduka and @t-hamano

Firstly, thanks for testing it @Mamaduka, and yes, the initial commit did not solve the editor side problem as it was an inline styling and I was not sure how to override it without using !important.

Secondly, thanks to @t-hamano. Your suggested fix for overriding the default inline styling is superb and it completes the patch for the editor side also.

So now this PR makes the code block behaviour as expected for both frontend and the editor.

One thing I am concerned of is will the changes made to the useDefaultStyle() function negatively affect any other component. I am 99% sure it won't since the element.style.whiteSpace = element.style.whiteSpace || whiteSpace; will only take the element's white-space style if it is defined but still wanted to know your opinion.

[Mamaduka]

element.style.whiteSpace = element.style.whiteSpace || whiteSpace;

This should be okay. If the consumer wants to override, then we should allow it, IMO. @ellatrix, what do you think?

[Mamaduka]

Works as expected; the new white-space behavior was also approved in the old #70301 (comment).

I'm going to merge this.