Format library: fix unsetting highlight color #37062
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +91 B (0%) Total Size: 1.11 MB
ℹ️ View Unchanged
|
ellatrix
added
[Package] Format library
ellatrix
force-pushed
the
fix/remove-highlight
branch
from
713fc36
to
f134ea8
Compare
ellatrix
added
the
Backport to WP 6.7 Beta/RC
youknowriad
reviewed
Dec 6, 2021
youknowriad
approved these changes
Dec 6, 2021
mcsf
reviewed
Dec 6, 2021
| @@ -17,6 +17,8 @@ import { removeFormat } from '@wordpress/rich-text'; | |||
| */ | |||
| import { default as InlineColorUI, getActiveColors } from './inline'; | |||
|
|
|||
| export const transparentValue = 'rgba(0, 0, 0, 0)'; | |||
There was a problem hiding this comment.
I pushed a commit replacing all remaining occurrences of this string in format-library with the new constant. This should decrease the chances of format mismatches creeping in — for example, if the setter uses a hardcoded string like rgba(0,0,0,0) (with no spaces), the logic breaks.
The module constant, coupled with the expanded test coverage, might be enough. Otherwise we could use a regular expression.
mcsf
reviewed
Dec 6, 2021
| const match = name.match( /^has-([^-]+)-color$/ ); | ||
| if ( match ) { | ||
| const [ , colorSlug ] = name.match( /^has-([^-]+)-color$/ ); | ||
| if ( name.startsWith( 'has-' ) && name.endsWith( '-color' ) ) { |
There was a problem hiding this comment.
There should be a comment here explaining that colorSlug may be more than one word long, lest someone reintroduce a naive regular expression.
mcsf
approved these changes
Dec 6, 2021
There was a problem hiding this comment.
Secondly, for named colors, we mistakenly don't take into account color slugs with dashes, so they never become active, and they cannot be unset. This PR also fixes that.
Do we have such slugs in our E2E environment? Could we test the scenario?
Regardless, LGTM!
It's not a general parsing CSS function, it's one specifically to parse the color from the style attribute. We have a similar function to parse the color from a class attribute.
We did implicitly. I made that explicit now. |
noisysocks
removed
the
Backport to WP 6.7 Beta/RC
noisysocks
pushed a commit
that referenced
this pull request
Dec 13, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fixes #36532. If a transparent background color is set, it should be considered as no background set so that the format is removed when neither color not background color is set.
Secondly, for named colors, we mistakenly don't take into account color slugs with dashes, so they never become active, and they cannot be unset. This PR also fixes that.
How has this been tested?
Screenshots
Types of changes
Checklist:
*.native.jsfiles for terms that need renaming or removal).