Media Library modal opens randomly on AJAX requests

We have been struggling and debugging this issue for a couple months also. We have two different paragraph fields in the node edit form and it seems to behave exactly the same as described in the comments in this issue.

It seems like it is the combination of Paragraphs and Entity browser which results in the bug because in another project we have a similar setup but without Entity browser and we haven't encountered the same issue there. We can test if we can reproduce the issue with Paragraphs and core Media Library.

Sending the Ajax call seems to return the wrong element it replaces the wrong paragraph after the element is added. I originally reported the issue to Paragraphs module https://www.drupal.org/project/paragraphs/issues/3356796 🐛 Multiple paragraph fields in a single content type can cause conflicting behavior in frontend Active and there is also a video recording of the effect.

We've just experienced this issue, but it was reproducible each time on a particular Paragraph "Remove" button.

The node edit form was large; lots of paragraphs, fields, meta tags, schema.org metatags etc.

The issue was the _triggering_element_name was not present in the POST variables, even though it was sent by the browser.

We needed to increase the max_input_vars php setting from 1000 to 1200 (in our case)

This resolved it for us.

I checked our PHP settings to check the solution from #25. In our case max_input_vars is already set to 5000 but we are still experiencing the original issue. It is of course possible that our paragraph and node forms with multiple tabs are so large that even 5000 is not enough to hold the original variable.

@andyrigby could you give more detailed instructions how you tested that the _triggering_element_name is not present in the POST variables? I could try playing around with our test environment to see if I can reproduce the problem with our current settings and if raising the limit would help.

We tested increasing the max_input_vars to 10 000 but were still able to reproduce the issue. In our case it happens that if you are too quickly opening and closing a media modal it gets replaced by a paragraph element. It seems like the reason is that the previous modal request isn't completed when the next one starts so it seems like a race condition. It took us approximately 4-5 clicks of opening and closing the modal to get the wrong form displayed.

We're experiencing this issue also on Drupal 10.2.8.
Seems also that when this happens, content is lost upon save.

I think this should be major issue.

I added 🐛 Form cache causes issues with media library widget Active which I think might be related to this.

I just ran into this issue while working at ✨ Seamless entity reference autocomplete integration Needs work .

For us, this issue is not 100% reproducible. We have a massive edit form with a LOT of fields. This exact issue happens inside a paragraphs field which references a paragraph with the upcoming entity browser widget developed in ✨ Seamless entity reference autocomplete integration Needs work (with cardinality 1). When pressing the "Remove" button, sometimes (not always) the referenced entity won't get removed and instead the media library gets opened.

I step debugged into MediaLibraryWidget::openMediaLibrary() and interestingly enough it triggers, when pressing the "Remove" button. The triggering element is also the "media-library-open-button" for some reason, so it seems to mess up the triggering element.

Although when I check the triggering element through the user input, I get the actual "remove-button" as my triggering element.

$form_state->getTriggeringElement()['#name'] // This is the "media-library-open-button"
$form_state->getUserInput()['_triggering_element_name'] // This is "field_x_remove_1001384_0_bBhuaW[...]" (aka my remove button)

Now through comparing these values, we can return an AjaxResponse without the "OpenModalDialogCommand" early, if these names don't match. Unfortunately, this leads to the form not removing the entry properly, meaning the AJAX is not doing anything anymore. Meaning the issue has to happen before "openMediaLibrary" is called, but an interesting observation non the less.

Our "max_input_vars" is already at 5000 and the correct "_triggering_element_name" is part of the POST (as seen through `$form_state->getUserInput()['_triggering_element_name']`).

I also found out, that when the issue doesn't appear, we enter this if state:

      if ($this->elementTriggeredScriptedSubmission($element, $form_state)) {
        $form_state->setTriggeringElement($element);
      }

But when the remove button would usually open the media library (the incorrect behavior), it doesn't go into the if state, because this if state:

$element['#name'] == $input['_triggering_element_name']

returns FALSE, as the triggering element name is different from the element name, as the id is slightly different:

$input['_triggering_element_name'] = ''field_x_remove_1001384_0_bBhuaWAbk6TuBnwUG0wh3JIEtpaaBJHXGeoF07Or3iQ''
$element['#name'] = 'field_x_remove_1000020_0_bBhuaWAbk6TuBnwUG0wh3JIEtpaaBJHXGeoF07Or3iQ'

(The ID differs)

But this could be related to the widget implementation.