Update field style controls to use tools panel and live in the styles tab #42278

talldan · 2025-03-07T02:30:40Z

Proposed changes:

Moves the Form Field style controls to the Styles tab in block inspector. Also switches these controls over to using ToolsPanels and ToolsPanelItems so that they can be reset and are consistent with other blocks.

The main reason for moving to the style tab is to support the changes in #41805. That will result in core's layout sizing control appearing on field blocks in the styles tab, and it then becomes unusual to have some design tools in the styles tab and others still in settings. After this change design tools will consistently be in the styles tab.

I've changed the organization of the panels so that they're more consistent with core blocks, with 'Dimension', 'Border', 'Color' panels. However I still had to implement two slightly custom 'Typography' panels for the labels and inputs. More on that later in the PR description.

The changes are mostly within the JetpackFieldControls file which is used by several form fields to render the inspector controls. The Consent and Checkbox fields don't use this component and have their own implementation. The width control is also a separate component.

Issues and trade-offs

Initially I'd want to use core's color/dimensions/border InspectorControls groups. However these implement their own tools panel, and the reset functionality for those panels doesn't work with the field style syncing. @aaronrobertshaw mentioned that he worked on a refactor of the syncing to make that work in [PoC] Forms: Try using inner blocks for fields to aid styling via Global Styles #41281, so it might be an option to follow up with changes. As an alternative I've used custom tools panels for everything apart from width (which isn't synced so doesn't suffer from the issue).
The ordering of the tools panels matches core, apart from the dimensions panel. When Forms: Update form field support for container block layouts #41805 is merged, and a field block is used in a grid, row, or stack block, the block editor will inject its own dimensions tool and we have no control over the positioning, so I've made it that Jetpack's width control is shown in the same place as that control.
It's difficult to combine label and field typography into one tools panel. <FontSizePicker> doesn't seem to accept a label, so there aren't many options for making the controls distinctive within one panel. I'm open to feedback, particularly design feedback on how this might be improved, or whether it's ok as it is.
ColorGradientSettingsDropdown doesn't work out of the box in a tools panel, seems like has to be wrapped in a div with some styles attached.
I wasn't sure how best to move the 'Sync field style' option over to the Styles tab. I tried a few different options, and it felt best at the bottom of the panel. I made some small changes to the copy here as well, simplified it to 'Sync field style' and updated the help text to make it clear that Width isn't synced (maybe that's not needed?).
This PR doesn't change anything about the jetpack button block

Other information:

Have you written new tests for your changes, if applicable?
Have you checked the E2E test CI results, and verified that your changes do not break them?
Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Does this pull request change what data or activity we track or use?

No

Testing instructions:

Add a form, add consent and checkbox fields to the form along with other types of field
Try changing styles for the different types of field, ensure the styles apply correctly and are synced
In the settings dropdown for each panel, use the individual reset options and confirm they work and are synced
In the same dropdown also try the reset all option and confirm it works and is synced.
Switch off syncing
Repeat steps 2-4 again, and confirm styles changes apply but are not synced.

Screenshots

Before	After

github-actions · 2025-03-07T02:31:28Z

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack), and enable the update/field-style-controls-to-use-tools-panel-and-live-in-the-style-tab branch.
To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/field-style-controls-to-use-tools-panel-and-live-in-the-style-tab

Interested in more tips and information?

In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
Read more about our development workflow here: PCYsg-eg0-p2
Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

github-actions · 2025-03-07T02:31:38Z

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

✅ Include a description of your PR changes.
✅ Add a "[Status]" label (In Progress, Needs Review, ...).
✅ Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
✅ Add testing instructions.
✅ Specify whether this PR includes any changes to data or privacy.
✅ Add changelog entries to affected projects

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

Follow this PR Review Process:

Ensure all required checks appearing at the bottom of this PR are passing.
Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
You can use GitHub's Reviewers functionality to request a review.
When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

Jetpack plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

talldan · 2025-03-07T02:37:49Z

Seems like the build is failing. Strangely I didn't have any issues with watch locally. I'll switch to a draft while I fix it.

jp-launch-control · 2025-03-07T02:39:24Z

Code Coverage Summary

Coverage changed in 4 files.

File	Coverage	Δ%	Δ Uncovered
projects/packages/forms/src/blocks/contact-form/class-contact-form-block.php	92/184 (50.00%)	-6.10%	20 💔
projects/packages/forms/src/blocks/contact-form/components/jetpack-field-controls.js	0/56 (0.00%)	0.00%	16 💔
projects/packages/forms/src/blocks/contact-form/components/jetpack-field-checkbox.js	0/12 (0.00%)	0.00%	2 ❤️‍🩹
projects/packages/forms/src/blocks/contact-form/components/jetpack-field-consent.js	0/7 (0.00%)	0.00%	1 ❤️‍🩹

2 files are newly checked for coverage.

File	Coverage
projects/packages/forms/src/blocks/contact-form/components/jetpack-field-dimension-controls.js	0/7 (0.00%) 💔
projects/packages/forms/src/blocks/contact-form/util/use-tool-panel-responsive-dropdown-props.js	0/2 (0.00%) 💔

Full summary · PHP report · JS report

_{Coverage check overridden by

I don't care about code coverage for this PR
Use this label to ignore the check for insufficient code coveage.
.}

talldan · 2025-03-07T03:01:02Z

Should be working again now, it was an i18n issue.

tellthemachines

I just quickly tested this and the controls all seem to be working as expected, but theme colours aren't displaying in the colour palette:

My active theme is TT5 if that helps.

talldan · 2025-03-07T05:43:25Z

I just quickly tested this and the controls all seem to be working as expected, but theme colours aren't displaying in the colour palette:

Oh yes, thought it looked weird, but didn't realize it was missing something. 😄

talldan · 2025-03-10T02:31:26Z

I just quickly tested this and the controls all seem to be working as expected, but theme colours aren't displaying in the colour palette

This should be fixed now:

talldan · 2025-03-10T02:35:32Z

I'm skipping the code coverage check for this PR.

JetpackFieldControls could be broken up into smaller components to be unit tested, but it'd make this PR very hard to review. It was already a big monolith before I got here.

I think it'd better to write end to end tests for blocks. 🤷

aaronrobertshaw

Thanks for all the heavy lifting here @talldan 👍

Functionally, this is mostly testing well for me. There were only a couple of small issues e.g. the color palettes still needing fixing for the consent and checkbox fields, menu popover positioning due to copy/paste typo etc.

Other than that, it's only minor suggestions for improvement, which I've left as inline comments. Ignore the number of them, I just figured they'd help as a checklist and can be marked as resolved to suit.

As this PR will fix #41205 and address the ability to reset style controls, perhaps we can add fixes: #41205 to the PR description here too for discovery.

However I still had to implement two slightly custom 'Typography' panels for the labels and inputs.
...
It's difficult to combine label and field typography into one tools panel.

My initial thoughts were we should update the syncing of styles to be compatible with the core block supports' use of updateBlockAttributes but you make a great point about the inability to appropriately label and differentiate some of the typography controls. Unlike colors, the typography panel doesn't lend itself well to multiple "sets" of styles.

I think two separate custom panels is an acceptable short-term option while we wait for form fields to be converted to inner blocks. Providing a consistent UX here would be an automatic benefit to adopting more atomic blocks.

That said, this compromise shouldn't block this PR as I believe it's still an improvement over trunk.

I think it'd better to write end to end tests for blocks

Agreed, at least covering the happy path this way sounds like a good place to start.

ColorGradientSettingsDropdown doesn't work out of the box in a tools panel, seems like has to be wrapped in a div with some styles attached.

There's a long murky history with this component and its historical origin belonging to the PanelBody component.

Functionally the component does work out of the box within a ToolsPanel. Core's design direction was for the ToolsPanel to default to a two column grid layout. At the same time core's color panel design was to be a single column. When ColorGradientSettingsDropdown was being refactored to also support being in a ToolsPanelItem it was deemed best to leave the styling up to the consumer.

It would've been nice to have a prop to opt into some default column widths/layouts etc. I believe the thinking there was to avoiding adding stuff to the end API that then had to be supported moving forward.

projects/packages/forms/src/blocks/contact-form/components/jetpack-field-checkbox.js

projects/packages/forms/src/blocks/contact-form/components/jetpack-field-controls.js

talldan · 2025-03-13T04:16:57Z

Bug: Checkbox size doesn’t scale when increasing text size—this should be addressed.
Changing label size in a single checkbox should affect multi-choice options but not text-field labels.

@ilonagl These two things are not introduced by this PR they also happen in trunk, but I can work on separate fixes.

It also seems like for multi-choice / single-choice fields there's the opposite problem. Setting the text size scales the radio/checkbox, but not the text.

talldan · 2025-03-13T04:56:31Z

projects/packages/forms/src/blocks/contact-form/components/jetpack-field-controls.js

+					panelId={ clientId }
+					dropdownMenuProps={ toolsPanelDropdownMenuProps }
+				>
+					{ ( isChoicesBlock || blockStyle === 'button' ) && (


This replicates what's in trunk, but I'm a bit confused by this condition, because it looks like the 'button' style for is only available on 'choices' blocks (Multiple Choice / Single Choice), so the whole || blockStyle === 'button' part is meaningless.

When the block style is something other than button, these button border styles have no effect, but I'm not sure if that's the fault of this condition (perhaps it should be an &&?) or if the css is broken.

If you change the border style when the 'button' style is active, you can change the border width, but you can't set a border color, so in the theme I'm using it's a transparent border.

When you have a button style on a checkbox within a multiple choice field, the checkbox is still visible within the button:

This doesn't happen for the radio button.

I'll make sure to log these bugs if they're not already. All of these issues are happening in trunk for me.

I went looking for legacy use cases for the button block style that weren't associated with the choice fields and didn't see any signs of it. I only went back as far as the PR that refactored all the choice fields (#39141). At that stage I didn't see it used for other fields.

So given that, I think you're right, this can be cleaned up. The bugs noted and the clean up sound like a good follow up to me.

talldan · 2025-03-13T07:13:09Z

Thanks for all the thorough reviews everyone, I believe I've addressed all the feedback now.

aaronrobertshaw

Thanks for addressing all that feedback @talldan 🚀

I've left some additional feedback on things that need tweaking via inline comments.

Those aside, I'm still not sold that we should be making end users adapt to consecutive UX changes. This isn't a problem per se with this PR more that it could pay to hold off on it until it's confirmed we won't be moving to inner blocks for form fields in the near future.

This concern could be mitigated some by the idea you shared in a sync call around levering the block editor setting that opts out of separate tabs display in the block inspector. In other words, we can keep all the styles controls within the same simple block inspector without tabs that the field blocks have now.

Did you end up exploring this at all?

If not, the block editor setting, blockInspectorTabs, was stabilized in Gutenberg back in WordPress/gutenberg#47045. It does allow finer grained control on a per block basis too.

projects/packages/forms/src/blocks/contact-form/components/jetpack-field-checkbox.js

projects/packages/forms/src/blocks/contact-form/components/jetpack-field-controls.js

aaronrobertshaw · 2025-03-14T07:52:50Z

projects/packages/forms/src/blocks/contact-form/components/jetpack-field-controls.js

+					panelId={ clientId }
+					dropdownMenuProps={ toolsPanelDropdownMenuProps }
+				>
+					{ ( isChoicesBlock || blockStyle === 'button' ) && (


I went looking for legacy use cases for the button block style that weren't associated with the choice fields and didn't see any signs of it. I only went back as far as the PR that refactored all the choice fields (#39141). At that stage I didn't see it used for other fields.

So given that, I think you're right, this can be cleaned up. The bugs noted and the clean up sound like a good follow up to me.

projects/packages/forms/src/blocks/contact-form/components/jetpack-field-dimension-controls.js

projects/packages/forms/src/blocks/contact-form/editor.scss

talldan · 2025-03-18T04:48:08Z

Those aside, I'm still not sold that we should be making end users adapt to consecutive UX changes. This isn't a problem per se with this PR more that it could pay to hold off on it until it's confirmed we won't be moving to inner blocks for form fields in the near future.

This concern could be mitigated some by the idea you shared in a sync call around levering the block editor setting that opts out of separate tabs display in the block inspector. In other words, we can keep all the styles controls within the same simple block inspector without tabs that the field blocks have now.

Did you end up exploring this at all?

@aaronrobertshaw There was a small convo about it here - p1741752319463899-slack-C086RGTJT1D.

@simison felt it was fine to go ahead with the change.

I do share some of the concerns though. Here's what a less disruptive alternative might look like - #42525. With all the settings and design tools in the same tab we might choose not to show some of the controls by default, but those are things that can be easily adjusted.

edit: PR feedback should be addressed as well.

aaronrobertshaw · 2025-03-18T06:17:32Z

There was a small convo about it here - p1741752319463899-slack-C086RGTJT1D.

Thanks for the context @talldan. Unfortunately, I think there were some flawed assumptions in that conversation.

This PR will introduce style tab, which is the biggest "wait where are the options?" change from customer perspective.

The inner blocks won't have tabs in the inspector as they should only have styles controls. So this switch to using the styles tab wouldn't actually begin to smooth the change for users.

With all the settings and design tools in the same tab we might choose not to show some of the controls by default, but those are things that can be easily adjusted.

I think the approach you've taken in #42525 is probably more aligned with what inner block based fields would look like.

If we end up with a different approach like somehow trying to use elements for Global Styles purposes (I don't think this is a good option though), that would still require ad hoc controls at this field level. Even then, #42525 would align with that without preventing us from still adopting the tabs later on as the sidebar became more overloaded.

My personal opinion is we should probably leave all the input and label typography controls as optional (not displayed by default).

I do share some of the concerns though

Ultimately, there are a range of efforts either blocked or in limbo until a final decision is made on the inner blocks approach. Given that, I believe that decision has to come in the very near future. If that time frame, is only a few days or a week, there is no harm in holding off on merging this.

Alternatively, I think a reasonable compromise is to refine #42525 and merge it into this branch. The result will be to minimise UX changes for users yet progress or fix issues like being unable to reset some style fields.

Edit: P.S. recent code changes addressing feedback LGTM 👍

simison · 2025-03-18T08:33:03Z

This PR will introduce style tab, which is the biggest "wait where are the options?" change from customer perspective.

The inner blocks won't have tabs in the inspector as they should only have styles controls. So this switch to using the styles tab wouldn't actually begin to smooth the change for users.

Right! Yeah my bad and you're right; although some of the more elaborated blocks had settings/styles separated to tabs?

Anyway, I'm still not concerned about continuous changes to forms, and trying to hold everything for one big change at once. Forms are "set once and be done" type action; customers aren't continuously returning to the sidebar and getting confused. Change is good too; it shows improving vs stalled product.

The copy changes to the sync toggle here are excellent, make the toggle much clearer, so would love to get that in asap.

keoshi · 2025-03-18T09:21:24Z

Jumping in to offer a suggestion, but feel free to ignore.

To me "Toggle off if you want to style this block only." doesn't make much sense since it's not aligned with the label. It mentions the opposite of what the label is doing resulting in conflicting instructions IMO.

I'd suggest something like "Ensures all form fields share the same styling." and potentially adding the negative case afterwards: "Ensures all form fields share the same styling. Turn off to customize this block separately."

If you want to keep the opposite case would suggest cleaning up the wording: “Turn off to customize this block separately."

Also have a question about the position. What styles are synced across form fields? Would expect width to also be synced but given the toggle is below it, it doesn't seem like it does?

simison · 2025-03-18T10:14:20Z

Thanks @keoshi ! "Ensures all form fields share the same styling." sounds great and short. 👍 Will be great to have it in human language vs the technical "sync".

Also have a question about the position. What styles are synced across form fields? Would expect width to also be synced but given the toggle is below it, it doesn't seem like it does?

Nope, the width doesn't sync; only things below the toggle.

That said, since it's more like an advanced setting that should be rarely needed, it might be better to place it at the end or within "Advanced" panel. For now current placement seems fine, above everything that syncs.

aaronrobertshaw · 2025-03-19T02:14:39Z

FWIW I have a small concern about the wording of the sync toggle.

Both "Apply styling to all fields" and "Ensures all form fields share the same styling" are inaccurate. This setting only opts this field into sharing styles with other fields that have also opted in. In other words, it might not be "all fields" or "all form fields". The proposed wording could also imply it's "all fields" across all forms.

aaronrobertshaw · 2025-03-19T02:16:27Z

Anyway, I'm still not concerned about continuous changes to forms, and trying to hold everything for one big change at once.

We can still limit the bumps in the road for end users by adopting #42525 for very little extra effort.

ilonagl · 2025-03-19T16:44:05Z

I'd suggest something like "Ensures all form fields share the same styling."

Thank you for jumping in, @keoshi!

Both "Apply styling to all fields" and "Ensures all form fields share the same styling" are inaccurate. This setting only opts this field into sharing styles with other fields that have also opted in. In other words, it might not be "all fields" or "all form fields". The proposed wording could also imply it's "all fields" across all forms.

Great catch, @aaronrobertshaw! You're right. What about adding a small info icon near the header with a tooltip/popover explanation that clarifies what this means ('This setting only opts this field into sharing styles with other fields that have also opted in' or something similar) until we figure out a better way for this (especially if we do decide to use inner blocks and global styling)?

We can still limit the bumps in the road for end users by adopting #42525 for very little extra effort.

@aaronrobertshaw, you make a good point here. IMHO, it all depends on the timeline. If we introduce the style tab and then revert it within a week or two, I’m not sure it’s worth it. But if it's closer to a month, then @simison is right—it’s better to show that we’re making improvements, even if it might introduce some bumps along the way.

aaronrobertshaw · 2025-03-20T03:59:20Z

What about adding a small info icon near the header with a tooltip/popover explanation that clarifies what this means

I think anything is better than making a false promise with the copy.

If we introduce the style tab and then revert it within a week or two, I’m not sure it’s worth it.

That's the thing, we don't need to introduce the style tab at all. We can still make changes and improvements right now by adopting the simple addition to settings in #42525.

ilonagl · 2025-03-24T11:39:47Z

That's the thing, we don't need to introduce the style tab at all. We can still make changes and improvements right now by adopting the simple addition to settings in #42525.

I agree with this point.

Ultimately, it's @simison call of how we want to proceed forward.

simison · 2025-03-24T12:02:14Z

If it's not too much effort, we can move forward with the tab-less alternative in #42525, and then once we see how we proceed with blocks-support, we can decide how the next step should look.

Move color settings to styles tab in existing color panel Move JetpackFieldWidth to styles tab Rename JetpackFieldWidth to JetpackFieldDimensionControls to reflect the new top level component Move border controls to border tools panel Tidy up copy Ensure dropdowns open to left of inspector Remove isShownByDefault for many of the fields Move consent field color tools into style tab color tools panel Move checkbox field style controls to styles tab Avoid using the core InspectorControls groups due to resetAll not triggering styles sync. Mimic core panels using custom ToolsPanels Move typography tools panel above border Refactor consent field to use a standard tools panel instead of the block supports one Update checkbox field to use standard tools panel instead of block supports tools panel Fix resetting width Move field syncing to the style tab Fix border hasValue check against a value of 0 changelog Add 0 arg back to i18n call Show theme colors in color controls Update Consent and Checkbox blocks to include theme colors in color control Fix incorrect prop name - ensure tools panel dropdowns are positioned to the side of the sidebar Update copy to "Sync field styles" Sentence case panel headers Make the color control wrapper class a general purpose thing Update checkbox block typography panel copy Show font size controls by default Relocate and update copy for sync button Reset all resetAlls Switch to use using PanelBody for sync toggle and ensure Consent and Checkbox blocks have consistent implementations Move dimension control help text to ToggleGroupControl Fix multiline comment formatting Add docs for useToolsPanelResponsiveDropdownProps

talldan · 2025-03-31T07:50:29Z

If it's not too much effort, we can move forward with the tab-less alternative in #42525, and then once we see how we proceed with blocks-support, we can decide how the next step should look.

I've cherry-picked that commit into this branch and also rebased the branch.

I think that's all the feedback addressed?

talldan · 2025-04-02T07:02:22Z

@simison - @aaronrobertshaw has mentioned privately that he still has reservations about merging this PR, due to conflicts it'll cause with his ongoing work on #42353 and also that it's still changing things for customers in quick succession.

I think I'll abandon this, the longer it has taken the less it has become necessary with #42353 sounding like it's getting closer to something concrete.

I'll need to find another way to unblock the layout PR I worked in #41805, it might have been forgotten along the way, but that was one of my main motivations for this PR. Hopefully I can just apply the change in #42525 to that PR and it should ensure the width controls on the field blocks don't appear in the styles tab on their own.

talldan self-assigned this Mar 7, 2025

github-actions bot added [Block] Contact Form Form block (also see Contact Form label) [Feature] Contact Form [Package] Forms [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ labels Mar 7, 2025

talldan requested review from tellthemachines, andrewserong, aaronrobertshaw and a team March 7, 2025 02:34

talldan mentioned this pull request Mar 7, 2025

Forms: Make field style panels consistent with colors and allow resetting #42242

Closed

talldan marked this pull request as draft March 7, 2025 02:37

github-actions bot added the [Status] In Progress label Mar 7, 2025

talldan marked this pull request as ready for review March 7, 2025 03:00

tellthemachines reviewed Mar 7, 2025

View reviewed changes

talldan force-pushed the update/field-style-controls-to-use-tools-panel-and-live-in-the-style-tab branch from 1db8099 to 5b20287 Compare March 10, 2025 02:29

talldan added the I don't care about code coverage for this PR Use this label to ignore the check for insufficient code coveage. label Mar 10, 2025

talldan added the [Status] Design Input Requested label Mar 10, 2025

talldan requested a review from ilonagl March 10, 2025 03:32

aaronrobertshaw reviewed Mar 10, 2025

View reviewed changes

talldan force-pushed the update/field-style-controls-to-use-tools-panel-and-live-in-the-style-tab branch from 5b20287 to 8e1e8bc Compare March 13, 2025 04:50

talldan commented Mar 13, 2025

View reviewed changes

This was referenced Mar 14, 2025

Forms: Checkbox doesn't scale when changing text size #42446

Open

Forms: Multiple Choice checkbox styles work inconsistently and aren't synced with Checkbox styles #42447

Open

aaronrobertshaw reviewed Mar 14, 2025

View reviewed changes

talldan force-pushed the update/field-style-controls-to-use-tools-panel-and-live-in-the-style-tab branch from 596cdbf to 3102562 Compare March 18, 2025 02:58

talldan mentioned this pull request Mar 18, 2025

Forms: Update field style controls to use tools panel with single block inspector tab #42525

Closed

3 tasks

talldan added 2 commits March 31, 2025 15:25

Add block editor setting disable tabs for field blocks

8dfc3d7

talldan force-pushed the update/field-style-controls-to-use-tools-panel-and-live-in-the-style-tab branch from 3102562 to 8dfc3d7 Compare March 31, 2025 07:26

talldan closed this Apr 2, 2025

talldan deleted the update/field-style-controls-to-use-tools-panel-and-live-in-the-style-tab branch April 2, 2025 07:03

github-actions bot removed [Status] Design Input Requested [Status] Needs Team Review Obsolete. Use Needs Review instead. [Status] In Progress labels Apr 2, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update field style controls to use tools panel and live in the styles tab #42278

Update field style controls to use tools panel and live in the styles tab #42278

talldan commented Mar 7, 2025 •

edited

Loading

github-actions bot commented Mar 7, 2025 •

edited

Loading

github-actions bot commented Mar 7, 2025 •

edited

Loading

talldan commented Mar 7, 2025

jp-launch-control bot commented Mar 7, 2025 •

edited

Loading

talldan commented Mar 7, 2025

tellthemachines left a comment

talldan commented Mar 7, 2025 •

edited

Loading

talldan commented Mar 10, 2025

talldan commented Mar 10, 2025 •

edited

Loading

aaronrobertshaw left a comment

talldan commented Mar 13, 2025

talldan Mar 13, 2025 •

edited

Loading

aaronrobertshaw Mar 14, 2025

talldan commented Mar 13, 2025

aaronrobertshaw left a comment

aaronrobertshaw Mar 14, 2025

talldan commented Mar 18, 2025 •

edited

Loading

aaronrobertshaw commented Mar 18, 2025 •

edited

Loading

simison commented Mar 18, 2025

keoshi commented Mar 18, 2025

simison commented Mar 18, 2025

aaronrobertshaw commented Mar 19, 2025

aaronrobertshaw commented Mar 19, 2025

ilonagl commented Mar 19, 2025

aaronrobertshaw commented Mar 20, 2025

ilonagl commented Mar 24, 2025

simison commented Mar 24, 2025

talldan commented Mar 31, 2025

talldan commented Apr 2, 2025

Update field style controls to use tools panel and live in the styles tab #42278

Update field style controls to use tools panel and live in the styles tab #42278

Conversation

talldan commented Mar 7, 2025 • edited Loading

Proposed changes:

Issues and trade-offs

Other information:

Does this pull request change what data or activity we track or use?

Testing instructions:

Screenshots

github-actions bot commented Mar 7, 2025 • edited Loading

github-actions bot commented Mar 7, 2025 • edited Loading

talldan commented Mar 7, 2025

jp-launch-control bot commented Mar 7, 2025 • edited Loading

Code Coverage Summary

talldan commented Mar 7, 2025

tellthemachines left a comment

Choose a reason for hiding this comment

talldan commented Mar 7, 2025 • edited Loading

talldan commented Mar 10, 2025

talldan commented Mar 10, 2025 • edited Loading

aaronrobertshaw left a comment

Choose a reason for hiding this comment

talldan commented Mar 13, 2025

talldan Mar 13, 2025 • edited Loading

Choose a reason for hiding this comment

aaronrobertshaw Mar 14, 2025

Choose a reason for hiding this comment

talldan commented Mar 13, 2025

aaronrobertshaw left a comment

Choose a reason for hiding this comment

aaronrobertshaw Mar 14, 2025

Choose a reason for hiding this comment

talldan commented Mar 18, 2025 • edited Loading

aaronrobertshaw commented Mar 18, 2025 • edited Loading

simison commented Mar 18, 2025

keoshi commented Mar 18, 2025

simison commented Mar 18, 2025

aaronrobertshaw commented Mar 19, 2025

aaronrobertshaw commented Mar 19, 2025

ilonagl commented Mar 19, 2025

aaronrobertshaw commented Mar 20, 2025

ilonagl commented Mar 24, 2025

simison commented Mar 24, 2025

talldan commented Mar 31, 2025

talldan commented Apr 2, 2025

talldan commented Mar 7, 2025 •

edited

Loading

github-actions bot commented Mar 7, 2025 •

edited

Loading

github-actions bot commented Mar 7, 2025 •

edited

Loading

jp-launch-control bot commented Mar 7, 2025 •

edited

Loading

talldan commented Mar 7, 2025 •

edited

Loading

talldan commented Mar 10, 2025 •

edited

Loading

talldan Mar 13, 2025 •

edited

Loading

talldan commented Mar 18, 2025 •

edited

Loading

aaronrobertshaw commented Mar 18, 2025 •

edited

Loading