Sticky actions fail on Ajax

As you reported this as being an issue on rc15, can you reproduce this issue on either stable release 3.0 or 4.0.2?

I'm pretty confident that we've fixed this in rc16+

This is current 4.0.x:

https://git.drupalcode.org/project/gin/-/blob/4.0.x/js/more_actions.js?r...

formId is still directly used as selector for data-drupal-selector.

Want me to write an MR? If yes, what approach would you prefer?

So, the code needs to either query by ID instead of data-drupal-selector, or get the selector by ID first, and then use that next.

Yes, feel free to spin up a MR with a fix and adding steps how we can reproduce it!

The id is being used which generally would be correct as it gets updated by the context object in an Ajax request running through Drupal behaviors. In my short testing with an simple Ajax form this seems to work as expected and the id gets replaced with each Ajax call. But maybe your user case does not run through this function somehow.

I've also quickly did spin up an vanilla instance on tugboat here: https://master-oipts4sjqrrbzlm2ezjy0rvvw0jnjxkj.tugboatqa.com/admin/stru...

(admin/admin) and if you change the "Allowed number of values" it sends an Ajax request and the id gets changed, Save gets the updated form id and form selector id.

Cheers!

Well, perfect example actually. See attached Screenshot of the tugboat install.

form ID and data-drupal-selector diverge after AJAX call. So the more-actions.js code does not apply anymore.

It seems however, that it is simply not executed here?

Thanks for the clarification! Yes, this seems to be wrong.

Why the use case I was testing still works as expected: For that button to function correctly, the important part is what gets set on the submit button themselves. The form attribute is referring to the id of the form and the data-gin-sticky-form-selector is referring to the the action being triggered (also an id). This seems to be correctly set. As this button doesn't have to rely on the additional click() event from JS as it can directly (natively) trigger the id which is defined in the form attribute on the button (that's an native HTML feature). That's why this still works as expected.

So in a nutshell, if that's not the case for a form action the JS never gets triggered in the first place because of the id and data-drupal-selector selector mismatch.

If you can spin up an MR which changes the part within the if (buttonSelector) {} to use [id="${formId}"] instead of [data-drupal-selector="${formId}"] this should be fixed.

We might want to additionally exit the function when the form attribute exists on the action and is available in the dom, but this could be done in a follow-up.

For which version? 4.0.x? And then run webpack dev? Anyway, tomorrow...

christianadamski → closed merge request !571

I tested locally with 3.0-rc15 and transferred the changes manually. So didn't technically test 4.x, but the code is identical, so should be the same.

Hey @christianadamski thanks for creating an MR, I left one comment 👀

Ok, good to go I guess.

Use once to add eventlistener for button sync. Added mousedown event in case of ajax buttons, see 🐛 custom ajax button not working anymore Active

I can confirm that the patch with the addition of Volker's change restores AJAX button functionality.

@christianadamski can you confirm that the latest added changes still work in your case? Thank you

RTBC +1

Thanks! 👏

Released & included in 4.0.3

https://www.drupal.org/project/gin/releases/4.0.3 →

Automatically closed - issue fixed for 2 weeks with no activity.