Flaky tests detected in 8be747e.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17120347203
📝 Reported issues:

• [Flaky Test] should refresh the page when stylesheet loading fails #71135 in /test/e2e/specs/interactivity/router-styles.spec.ts

Thank you for the thorough check @carolinan!
I pushed an additional commit, fixing the issue 👍

Size Change: +151 B (+0.01%)

Total Size: 1.92 MB

_{compressed-size-action}

What is the root cause of styles and classes not being applied on both the editor side and the front end side? My understanding is that the useblockProps hook should automatically give them those styles and classes.

Does it have something to do with this block being experimental? 🤔

What is the root cause of styles and classes not being applied on both the editor side and the front end side? My understanding is that the useblockProps hook should automatically give them those styles and classes.

It was an error of omission... In the initial POC implementation, I just forgot to add them. The style was missing completely, and the classname was hardcoded to wp-block-form without getting any of the other ones added from colors, borders etc

I understand why. Although the blockProps hook has already been introduced, the className is false and the class name wp-block-form is hard-coded.

Is there any reason to make className false? If not, I think all we need to do is make the following changes.

diff --git a/packages/block-library/src/form/block.json b/packages/block-library/src/form/block.json
index 0c6451f495..b79c9f9249 100644
--- a/packages/block-library/src/form/block.json
+++ b/packages/block-library/src/form/block.json
@@ -27,7 +27,6 @@
        },
        "supports": {
                "anchor": true,
-               "className": false,
                "color": {
                        "gradients": true,
                        "link": true,
:...skipping...
diff --git a/packages/block-library/src/form/block.json b/packages/block-library/src/form/block.json
index 0c6451f495..b79c9f9249 100644
--- a/packages/block-library/src/form/block.json
+++ b/packages/block-library/src/form/block.json
@@ -27,7 +27,6 @@
                "anchor": true,
-               "className": false,
                "color": {
                        "gradients": true,
                        "link": true,
diff --git a/packages/block-library/src/form/edit.js b/packages/block-library/src/form/edit.js
index 7fded64837..7f479a9b2c 100644
--- a/packages/block-library/src/form/edit.js
+++ b/packages/block-library/src/form/edit.js
@@ -172,7 +172,6 @@ const Edit = ( { attributes, setAttributes, clientId } ) => {
                        ) }
                        <form
                                { ...innerBlocksProps }
-                               className="wp-block-form"
                                encType={ submissionMethod === 'email' ? 'text/plain' : null }
                        />
                </>
diff --git a/packages/block-library/src/form/save.js b/packages/block-library/src/form/save.js
index a824fc076d..9d944f13ef 100644
--- a/packages/block-library/src/form/save.js
+++ b/packages/block-library/src/form/save.js
@@ -10,7 +10,6 @@ const Save = ( { attributes } ) => {
        return (
                <form
                        { ...blockProps }
-                       className="wp-block-form"
                        encType={ submissionMethod === 'email' ? 'text/plain' : null }
                >
                        <InnerBlocks.Content />
~
~

Also, this PR requires deprecation because it changes the save markup, but as reported by #56590 there is an issue with fixture tests not working correctly.

You're right, the className in block.json should not be false. I pushed a commit to fix that.
However, I tried your suggestion and it didn't work... It looks like all the other stuff is needed too. Upon further examination, I saw we do the same thing in the button block, the search block, as well as various others like image and so on.

Upon further examination, I saw we do the same thing in the button block, the search block, as well as various others like image and so on.

I think this kind of approach is mainly used when styles need to be applied to the elements inside the block rather than the wrapper. Styles and classes should be applied correctly to the block wrapper unless we are using __experimentalSkipSerialization.

I pushed f8ee53e with the changes. In my testing, both global and block-specific styles appear to be applied correctly. Could you test this commit once?

Huh... Confirmed, it works ❤️
Thank you!

I'm glad to know it worked correctly.

The code looks good, but in order to ship this PR, I think the following two actions are necessary:

• Rebase this PR with the latest trunk branch: This is because #56590, which ensures form-related fixtures are generated correctly in the fixture test, is included.
• Regenerate the fixture file via the npm run fixtures:regenerate command.

Done.
npm run fixtures:regenerate didn't change anything so I assume we're OK 👍

Sorry, I forgot to tell you one more thing 😅

This PR is updating the save function, so you need to add a block deprecation. This will update existing fixture files when you run npm run fixtures:regenerate. Additionally, there is a need to add a new fixture as well.

Thank you for replying @aaronrobertshaw

Can you expand at all on what wasn't working with the deprecation? Some steps to replicate the problem would be helpful.

The main issue I faced is in the UI.
Steps to replicate:

• Using trunk add a form block in the editor
• Change background-color, text-color and play with the styles a bit
• Switch to this branch and reload the editor

The error: Expecting the deprecation to kick-in and work, migrating the content. What actually happens: Still getting the invalid-block error. As soon as I hit the recovery button everything works, but that's not what we expect when adding migrations

Thanks for the extra details 👍

It still sounds like an issue we should be able to fix with the deprecation. Have you by any chance done some debugging around where block deprecations are applied to see what's going on in this case?

My understanding is that the form block isn't being stabilized for WP6.6, so there is no urgency to have this sorted before the WP6.6. beta, correct? I'd be happy to dig deeper in a week or two if that's the case.

Have you by any chance done some debugging around where block deprecations are applied to see what's going on in this case?

Yeah, tried to understand it for weeks and couldn't understand what goes on there... so to be honest I gave up. Deprecations make my head spin, so I moved on to other issues 😅

My understanding is that the form block isn't being stabilized for WP6.6, so there is no urgency to have this sorted before the WP6.6. beta, correct?

That is correct. this is not an urgent task 👍

Deprecations make my head spin

Don't worry, you aren't alone there. Happens every time I have to revisit the area.

That is correct. this is not an urgent task 👍

Great, then in that case let's see what we can come up with once I can free up some bandwidth.

Appreciate your patience on this one.

I also investigated this issue again. I tried the deprecation suggested in this comment and it seems to work in some scenarios, but not completely.

For example, this deprecation works if the original markup does not include inline styles:

However, if the markup contains inline styles, deprecation will cause an error.

It feels like one more step, but I'm pushing the deprecated code again so you can test this issue.

Interesting #61833 submitted. It is mentioned that deprecation fails when blockProps is not used.

The Form block has blockProps applied, but the class name is overridden. Maybe this PR is also related to #61833.

Any thoughts on continuing the work on this PR?
As well as doing some additional work on the Form block?
The questions goes out to anyone....

The reason we can't rework this PR is that we haven't yet found a way to prevent this PR from breaking blocks. We haven't yet identified the cause, whether it's an error in our block deprecation code or a problem with the core deprecation logic itself 😅

OK, I think 3e9c06a fixed the problem.

However, if the markup contains inline styles, deprecation will cause an error.

We explicitly left the supports field empty to properly enforce deprecation. As a result, even if the Form block has custom values via block supports, the useBlockProps.save hook will not output inline styles. This results in the deprecation not matching and not executing.

To avoid this, I explicitly generate the inline styles that useBlocksProps.save would have added, and applied them to the wrapper element. Similarly, this issue also occurred with anchor support, so I revised the anchor attribute definition to explicitly apply an ID to it.

Based on my testing, deprecation should now work in all scenarios!

@aaronrobertshaw Ultimately, I believe we've applied the block deprecation correctly, and would appreciate your reviewing this PR for shipping 🙏