Fix: Add the border width on initial color change for border

[hbhalodia]

What?

Fixes: #69094

• PR adds the condition of undefined on initial render to set the width to 1px for border, if user adds/changes the color before explicitly setting the width.

Why?

• Closes - Gutenberg border block setting should be working properly. #69094
• It solves the issue related to border width not set when adding the color at first before explicitly setting the width.

How?

• PR adds the undefined condition with the 0 width check.

Testing Instructions

1. Open any page/post.
2. Add any paragraph.
3. Go to inspector control and enable border.
4. Set the border color first, you would notice it would also add 1px width for border.

Testing Instructions for Keyboard

• None

Screenshots or screencast

BorderFix.mov

[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: hbhalodia <hbhalodia@git.wordpress.org>
Co-authored-by: coder-rancho <vyasnaman@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: viralsampat-multidots <mdviralsampat@git.wordpress.org>

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

[mirka]

It looks like theme.json supports any string as border width (e.g. thin, var()), and that gets sent down to this component. The component can't render those values correctly in that case, but regardless, is it a problem that we silently overwrite these intentional string values with 1px? (cc @aaronrobertshaw)

[mirka]

The changelog needs to be repositioned.

Also, I don't think we need to mention useBorderControlDropdown specifically, since that's internal.

[hbhalodia]

Thanks @mirka, This is now updated.

[t-hamano]

Blocks may already have borders applied via global styles or custom CSS. In such cases, simultaneously adding a 1px width along with a color change might cause confusion.

border.mp4

It looks like theme.json supports any string as border width (e.g. thin, var()), and that gets sent down to this component. The component can't render those values correctly in that case, but regardless, is it a problem that we silently overwrite these intentional string values with 1px? (cc @aaronrobertshaw)

There was a similar discussion in the past regarding whether one border property should be changed simultaneously with another. #75431 (comment)

Considering that opinion, it might be better not to add the 1px width. cc @aaronrobertshaw @ramonjd @andrewserong @talldan

[ramonjd]

Thanks for the ping!

In my testing, this PR introduces something similar to what was discussed over in #75431 (comment)

There, the change discards the user's explicit color choice from global styles.

Here, it's discarding the explicit width:

Kapture.2026-08-26.at.11.45.26.mp4

I think the idea that he user should be able to view the border immediately when setting a color and not a width is a worthy one to think about, but I don't think we should cause unexpected changes.

A theme that defines a border width presumably wants to enforce that unless an editor explicitly changes it via the control, not via the side-effect of another control.