Rerolled latest patch for 10.3.
Rerolled the latest patch for 2.0.0-beta2.
Adding a patch in case someone needs these changes for 2.39 (patch from MR diff didn't apply for me).
Pushed proposed change to fork and also uploading a patch in case someone needs it. Please review.
Now also with added packaging info
The latest patch still causes type errors. I extended the latest patch to also update references in ChainGroupPermissionCalculator.
The change is applied to horizontal_toolbar.scss, but this CSS is only used when you are specifically using the horizontal toolbar (which is a theme setting).
For me this doesn't fix the issue, since I am using the standard toolbar. But I assume it would be sufficient to apply the same changes to toolbar.scss as well.
Chewi3 → created an issue.
This is also currently an issue on webforms when offcanvas is enabled for editing. For now we can switch to dialogs using webform settings, but would be nice if this could be fixed (or at least patched for now).
Patch in #42 no longer applied for me in 10.2, so I rerolled it. Uploading in case someone else needs it for now.
I updated the patch from #9 so that it applies against 4.0 release. I did notice that EncloseField is marked as deprecated, so we should probably look into a more long term solution before we can think about merging this.
In my previous comment I forgot to account for node creation (which seems to correspond to the "default" operation). Which also means my fix needs to be slightly adjusted (I guess I can specifically add a "delete" content form mode instead and do it the other way around).
Adding an updated patch.
I haven't tested from a clean Drupal install, but the way it is currently set up does seems like a possible problem.
The entity_form_steps_form_alter hook checks if the form object is an instance of ContentEntityFormInterface. ContentEntityConfirmFormBase extends ContentEntityForm, so the node delete form is also altered.
Usually you only have the "default" form display mode. So if this is the form mode that has the step field groups, they will also be retrieved for the delete form (since it tries to look for a "delete" form mode, but defaults to the "default" form mode.
I did fix our problem by adding an extra content form mode next to the default. By adding an "edit" form mode with the steps and removing the steps from the default, the issue is fixed.
Not sure what a good fix would be, if it is even needed. I did add a patch with a possible solution (checking the form state operation and only altering the form when in 'edit mode'), so feel free to review if something like this could be helpful to add.
Added patch with my temporary solution (as mentioned in issue description).
I added a patch that changes the logic on the disable form cancel callback to be similar to the TfaSetupForm cancel callback logic.
Chewi3 → created an issue.
I came across the same problem today and had to use an AJAX callback as an alternative. You should probably make an actual ticket for this (not sure how much traction this forum post will have).
Chewi3 → created an issue.