Forms: Text area field gets incorrect border in block style previews

[aaronrobertshaw]

Impacted plugin

Jetpack

Quick summary

While testing #41415, I found there was a tiny visual regression to block style previews for forms introduced via #41274.

Before #41274	After #41274

Screen.Recording.2025-01-30.at.4.55.08.pm.mp4

Steps to reproduce

1. On trunk, add a contact form to a post
2. Select the contact form and switch to the Styles tab in the block inspector sidebar
3. Hover over one of the block style buttons to trigger the preview popover
4. Note that on the initial hover of a block style, the message text area field has a dark black border when it should match the other fields

Site owner impact

Fewer than 20% of the total website/platform users

Severity

Minor

What other impact(s) does this issue have?

No response

If a workaround is available, please outline it here.

No response

Platform (Simple and/or Atomic)

No response

[talldan]

It's related to window.jetpackForms.generateStyleVariables which is responsible for injecting css variables into the block. It returns values that change across component renders. Initially it returns undefined, then it returns an object with a --jetpack--contact-form--border-size property of 2, and then that border size changes to 1.

You can see this visually when the editor loads (this was also happening before #41274):

Kapture.2025-01-31.at.12.28.51.mp4

For some reason, since #41274, the block preview has the border size value 2. I checked out the commit before #41274 (4757d07), and in the block preview the border size stays undefined and never gets to 1. There are some fallback styles for the textarea that set the border to 1 when the CSS Var is undefined.

The main problem is generateStyleVariables function, which doesn't cause the block to re-render when its values change because it's not a hook. It only works because other updates to the block trigger re-renders. That function is a ticking time bomb for when it was going to cause a bug 😬. Fun for me that I encountered it!

Why does the block preview trigger these issues? I think it's because of the way the blocks in the preview are heavily optimized/memoized and the preview itself is only a minimal version of the block editor, so it causes fewer block re-renders. I'm only seeing two renders of the form block in the preview when I log it out, compared to around ~10 in a normal editor, likely because the proper editor has a lot of other stuff going on that causes more renders.

[talldan]

I'm really curious about how generateStyleVariables works and why it was implemented like this.

It injects some html (form markup) into the editor canvas:

jetpack/projects/packages/forms/src/blocks/contact-form/util/form-styles.js

Lines 29 to 41 in 3f88cfc

	const HTML = `
	<div class="contact-form">
	<div class="wp-block-button">
	<div class="wp-block-button__link btn-primary">Test</div>
	</div>
	<div class="wp-block-button is-style-outline">
	<div class="wp-block-button__link btn-outline">Test</div>
	</div>
	<div class="jetpack-field">
	<input class="jetpack-field__input" type="text">
	</div>
	</div>
	`;

It then reads back the CSS values from the injected html, and then sets those values as css vars, which some of the blocks use in their styles. After that it removes the html.

It seems like a way to adapt HTML that was written for one html/classname structure to another. Possibly taking the contact form shortcode styles so that they can be used for the block? But the markup has block classnames, so that has me confused.

It's fairly convoluted, it might have been easier and more robust to update the styles directly so that they work for the block, or build a shared set of css vars that both the block and the shortcode can use even if they target different classnames. Maybe there were reasons that couldn't be done.

Also of note, this function is used in both the editor and frontend, though it seems to have limited use on the frontend, I didn't test exhaustively, but it seems to mostly be used for padding.

#29178/#29359 seem to be the origin of this code, but don't have a lot of info.