Ajax behaviour on entity edit form action buttons can break

This patch fixes it for me.

That was too quick and not properly tested. This one is fixing the issue for me.

Confirming this issue. We're running into it when changing layout paragraphs sometimes.

This was also confirmed in 🐛 Problem with form submit button's not working after an ajax call would refresh the form-id Closed: duplicate (was closed as duplicate of this).

@Anybody can you rest if the patch fixes the issue for you?

@saschaeggi the problem is, that the issue only appears from time to time, so there's no reliable way to test it. Even if it works, it doesn't mean it does in general. So I think we need to ensure that in theory.

@Anybody The steps to reproduce from the issue description don't help you isolate the problem? It took me a while, but in the end I was able to reliably reproduce this issue in my setup.

This is a little bit similar to issue 3387363 🐛 z-index problem with media library widget Closed: works as designed : Ajax requests can break if the dependency declaration of libs is missing or conflicting (e.g. through duplication). In this case there is a conditional (Ajax), but undefined dependency of gin/edit_form on drupal.ajax.

In response to #7:
The problem is reproduceable, but you have to check if a library is included on page load, or added later through an Ajax request.

I think berliner's approach is a quite clever approach, which avoids unconditionally adding the drupal.ajax library on all forms.

OTOH, I wonder if the change of the button's id is really necessary? Doing a code search on the Gin folder, I can't see --gin-edit-form being used anywhere (except being created initially). Maybe we can refactor edit_form.js instead and remove the manipulation of the ID.

Patch #3 did not work for me. However patch #23 from the duplicate issue 🐛 Problem with form submit button's not working after an ajax call would refresh the form-id Closed: duplicate did work for me. Using that instead.

Reroll #23 (and #15) from #3276752

Rerolled #3 for rc9.

I would be in favour of not changing the ids in the first place though, just as hudri suggested. Removing unnecessary complexity is always preferable.

Going to move using an issue fork instead of patches. Still unsure, which patch to use as a foundation. I'll start with the original from @berliner.

The patch by @berliner (now applied to the current MR) fixes the issue described in "Steps to reproduce"!! Unfortunately, the issue I had locally, has not much to-do with the AJAX integration (I thought it would, but instead it seems to be caused by custom client code).

Nevertheless, we should get this issue fixed.

@sim_1, what exactly did not work for you? Were you testing the patch through the "Steps to reproduce"? Or do you have another example where the current Patch / MR doesn't fix the issue? Please give us more information.

LGTM! But setting to "postponed" regarding #10.

Ok, i'm doing my best to remember... I wish I'd written down more details when it was fresh. I wasn't following the reproduction steps exactly. I was also working with custom client code:
- a custom module
- in the .module file there is a form alter that adds two widgets, and then attaches an ajax callback to each.
- admin theme is gin

I believe then I was getting ajax errors in the console when trying to use the submit buttons. It wasn't all the time, only after ajax had been triggered on the form by using either of the fields with callbacks. I can try to go back and reproduce. But I am guessing that all I meant by the patch not working is that it didn't fix my particular issue (not the exact repo steps from this description), but the other patch did.

Thanks for the clarification @sim_1! This definitely sounds like the patch doesn't work as intended, if you got the time, feel free to reproduce it using the current MR! Otherwise, we should check both patches and see if we can find a middle ground between them. :)

The patch in #11 had a typo where sticky was called out of scope.
Here's the fixed patch.

I tried to apply #12 instead and I'm unable to submit the form after ajax runs.
With this patch, it works.

Still not working for me. Changing something in layout_paragraphs still causes this issue randomly.

Created a Quickfix for this, using position: sticky and flexbox to have basically the same experience (while it doesn't look that perfect, but it works).

I get the feeling that this get's a bit out of hand here.
Those last patches do not seem to address the original issue about the changed button ids and the outdated references in the ajax subsystem. #12 should fix the issue as demonstrated by the "steps to reproduce", so this should be reviewed and tested. The other patches seem to be about different issues. Maybe it would be better to create a new issue for those with sufficient information to reliably reproduce the problems and then fixing them.

This will be fixed with ✨ Move Action buttons to sticky header Fixed