Media Library modal opens randomly on AJAX requests

Hello, which paragraph version are you using?
My paragraph is different from yours. I downloaded the last dev version. See my scream shot.
Or is there anyway to configure and set the "Remove" button instead of the "Collapse" button?

Can you confirm this happens on the latest version of Paragraphs?

Hi,
I confirm this is still an issue. I'm able to reproduce it the same as OP.

Paragraphs: 1.12
Drupal core; 9.2.4

Drupal 8.9.x is now open only to security issues.

Good to see, we're not alone with this extremely disturbing issue.
The worse thing about this issue is, that you can't save the node afterwards. So all modifications are gone, you need to reload and startover.

I can't confirm the reproduction from the OP, maybe because we are using the experimental widget and i am not able to click the second 'delete' fast enough.

However, I'm not exactly sure when this happens with our configuration. I have videos from customers (8.x) where this problem appears, but I wasn't able to reproduce it the same way. But yeah .. it also happened to me very often, its some combination of creating & deleting paragraphs (maybe just specific bundles). So ..probably some kind of race condition.. i will keep watching this, hopefully i will be able to find a reproducible case.

And it still happens with our Drupal 9 configuration using layout_paragraphs, so this is still a thing..

Just had a look at this and guess it's either
a) entity_browser bug
or
b) paragraphs + entity_browser bug

It's hard to reproduce but in certain combinations when we click a paragraph "Edit" we expect the paragraph edit modal, but the server returns the entity_browser modal, while the triggering element in the request is the paragraph edit button correctly:

So it seems like the Media Browser "thinks" it should open and returns it ajax command instead of the paragraph edit, which should happen... strange!

"Auto open entity browser" is NOT enabled for any entity browser on our page.

Searched the entity_browser issues for possibly related issues:
#2857339: Modal auto-open conflicts with AJAX
#3045723: Entity browser with auto open opens on field settings form
#2897855: Entity browser modal dialog opens by pressing enter in any text field
#3008700: Prevent "auto_open" infinite loop

Furthermore I can confirm the modal, which is triggered (twice) is the same and is an media entity image field from the node entity (not from a paragraph). Like the original author wrote.

Just had the same in a different project where we use Media in Core and layout_paragraphs combined with image fields on the node entity using the media library widget.

When editing paragraphs sooner or later the node entity image field media library widget pops up with the following action:
action="/de/media-library?media_library_opener_id=media_library.opener.field_widget&media_library_allowed_types%5Bimage%5D=image&media_library_selected_type=image&media_library_remaining=1&media_library_opener_parameters%5Bfield_widget_id%5D=field_coverimage&media_library_opener_parameters%5Bentity_type_id%5D=node&media_library_opener_parameters%5Bbundle%5D=page&media_library_opener_parameters%5Bfield_name%5D=field_coverimage&media_library_opener_parameters%5Bentity_id%5D=86&media_library_opener_parameters%5Brevision_id%5D=1616&hash=xx"

Any ideas?

The strangest thing for me is now, that it's NOT only media entity browser, but also media library browser widget, which shows this problem.

It can't be cleanly reproduced. After reloading the page and doing the same steps again, it doesn't happen. Then sooner or later it happens again, so it seems to have some kind of "state". Any ideas to find the reason would be highly appreciated.

Okay, we're one step closer... I debugged that down and the Modal seems to appear as a result of this Exception in
web\core\lib\Drupal\Core\Form\FormBuilder.php:

    // After processing the form, if this is an AJAX form request, interrupt
    // form rendering and return by throwing an exception that contains the
    // processed form and form state. This exception will be caught by
    // \Drupal\Core\Form\EventSubscriber\FormAjaxSubscriber::onException() and
    // then passed through
    // \Drupal\Core\Form\FormAjaxResponseBuilderInterface::buildResponse() to
    // build a proper AJAX response.
    // Only do this when the form ID matches, since there is no guarantee from
    // $ajax_form_request that it's an AJAX request for this particular form.
    if ($ajax_form_request && $form_state->isProcessingInput() && $request->request->get('form_id') == $form_id) {
      throw new FormAjaxException($form, $form_state);
    }

Here's a screenshot of the backtrace I took in buildResponse() from the unwanted modal and the request:

I'm not sure yet, if that Exception is a result or the cause of the problem.

@larowlan: This was really hard to reproduce and track down, but now I think I have some interesting results, so we should decide how to proceed here:

1. This seems like a race condition bug for (Modal) commands in core. It currently does NOT seem to be DIRECTLY caused by any of: Media, Media Library, Entity Browser, Paragraphs or Layout Paragraphs! But as a result, the Modals of Media Library / Entity Browser / ... are triggered! And a module which uses Modals a lot, like Paragraphs is likely to be affected by this issue. So there's a good chance to run into this, if you're using a combination of these modules.
This also explains why it happens in so many different combinations, as listed above... in Drupal 8, Drupal 9, with media library or with entity browser, etc...

2. The issue (at least for (layout) paragraphs appears when CLOSING a modal (or clicking "cancel" which is the same action) and very fast open another modal. If you do this open-close-open-close repeatingly very fast on a page with several paragraphs, the bug is likely to appear. The amount of (paragraphs) items seems to increase the chance for this to happen, perhaps because the client or server requires more time for processing.

The _triggering_element_name is "cancel":
_triggering_element_name: cancel for the second (wrong) modal.

3. The difference between the expected AJAX response and the actual race condition response can be seen in the following example.
What we'd expect are the two commands:

• update_build_id
• closeDialog

Expected (returned when clicking slow and waiting 2-3 seconds between each click):

[
   {
      "command":"update_build_id",
      "old":"form-fCZ3oUeX4HKnoh6GfzNFmJBqx12H6Vr4LbDK3czawtM",
      "new":"form-ZiWQUMgU0ehAaMBBKg7qCDxuX0TL2c1cG8JOW-UUtCg"
   },
   {
      "command":"closeDialog",
      "selector":"#field-paragraphs-widget-entity-form",
      "persist":false
   }
]

Actual result of closing the dialog (race condition):

[
   {
      "command":"settings",
      "settings":{
         "ajaxPageState":{
            "theme":"gin",
            "theme_token":"kudgw2GHw5acQ8674oL-4hKmsx2hrzXE0cK88GAUd48",
            "libraries":"admin_toolbar\/toolbar.tree,admin_toolbar\/toolbar.tree.hoverintent,admin_toolbar_search\/search,admin_toolbar_tools\/toolbar.icon,ckeditor\/drupal.ckeditor,[... shortened here ...]"
         },
         "media_library":{
            "selection_remaining":1
         },
         [... shortened here ...]
      },
      "merge":true
   },
   {
      "command":"add_css",
      "data":"\u003Clink rel=\u0022stylesheet\u0022 media=\u0022all\u0022 href=\u0022\/core\/modules\/views\/css\/views.module.css?r6xk8d\u0022 \/\u003E\n\u003Clink rel=\u0022stylesheet\u0022 media=\u0022all\u0022 href=\u0022\/core\/themes\/claro\/css\/components\/media-library.ui.css?r6xk8d\u0022 \/\u003E\n\u003Clink rel=\u0022stylesheet\u0022 media=\u0022all\u0022 href=\u0022\/core\/themes\/claro\/css\/components\/views-exposed-form.css?r6xk8d\u0022 \/\u003E\n\u003Clink rel=\u0022stylesheet\u0022 media=\u0022all\u0022 href=\u0022\/core\/themes\/claro\/css\/components\/file.css?r6xk8d\u0022 \/\u003E\n\u003Clink rel=\u0022stylesheet\u0022 media=\u0022all\u0022 href=\u0022\/core\/themes\/claro\/css\/theme\/media-library.css?r6xk8d\u0022 \/\u003E\n"
   },
   {
      "command":"insert",
      "method":"append",
      "selector":"body",
      "data":"\u003Cscript src=\u0022\/core\/themes\/claro\/js\/media-library.ui.js?v=9.3.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/misc\/checkbox.js?v=9.3.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/themes\/claro\/js\/checkbox.js?v=9.3.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/modules\/media_library\/js\/media_library.click_to_select.js?v=9.3.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/themes\/contrib\/gin\/js\/overrides\/gin_media_library.view.js?v=9.3.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/modules\/media_library\/js\/media_library.ui.js?v=9.3.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/modules\/views\/js\/base.js?v=9.3.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/modules\/views\/js\/ajax_view.js?v=9.3.5\u0022\u003E\u003C\/script\u003E\n\u003Cscript src=\u0022\/core\/modules\/file\/file.js?v=9.3.5\u0022\u003E\u003C\/script\u003E\n",
      "settings":null
   },
   {
      "command":"update_build_id",
      "old":"form-ZiWQUMgU0ehAaMBBKg7qCDxuX0TL2c1cG8JOW-UUtCg",
      "new":"form-dkStBfBK-kMkCwTLEnQuM5YmX1ZmYtvqBJO-RSdUAdU"
   },
   {
      "command":"openDialog",
      "selector":"#drupal-modal",
      "settings":null,
      "data":"\u003Cdiv id=\u0022media-library-wrapper\u0022 class=\u0022media-library-wrapper\u0022\u003E\n  \n  \u003Cdiv id=\u0022media-library-content\u0022 class=\u0022media-library-content\u0022\u003E\u003Cdiv id=\u0022media-library-add-form-wrapper\u0022\u003E\u003Cform class=\u0022js-media-library-add-form media-library-add-form media-library-add-form--without-input media-library-add-form--upload\u0022 data-drupal-selector=\u0022media-library-add-form-upload-o-5tjnnzchw\u0022 enctype=\u0022multipart\/form-data\u0022 action=\u0022\/de\/media-library?media_library_opener_id=media_library.opener.field_widget\u0026amp;media_library_allowed_types%5Bimage%5D=image\u0026amp;media_library_selected_type=image\u0026amp;media_library_remaining=1\u0026amp;media_library_opener_parameters%5Bfield_widget_id%5D=field_coverimage\u0026amp;media_library_opener_parameters%5Bentity_type_id%5D=node\u0026amp;media_library_opener_parameters%5Bbundle%5D=page\u0026amp;media_library_opener_parameters%5Bfield_name%5D=field_coverimage\u0026amp;media_library_opener_parameters%5Bentity_id%5D=86\u0026amp;media_library_opener_parameters%5Brevision_id%5D=1616\u0026amp;hash=XdhTKs7jIM06R2XmYsg65T6V3RoELukFMTqN5OEj9W8\u0022 method=\u0022post\u0022 id=\u0022media-library-add-form-upload--o-5tJnnZcHw\u0022 accept-charset=\u0022UTF-8\u0022\u003E\n  \u003Cdiv class=\u0022media-library-add-form__input-wrapper js-form-wrapper form-wrapper\u0022 data-drupal-selector=\u0022edit-container\u0022 id=\u0022edit-container--K5Wb34lsULA\u0022\u003E\u003Cdiv id=\u0022ajax-wrapper--h8ZN00wQCbU\u0022\u003E\u003Cdiv class=\u0022js-form-item form-item js-form-type-managed-file form-type--managed-file js-form-item-upload form-item--upload\u0022\u003E\n      \u003Clabel for=\u0022edit-upload-upload--iaTOLH7U8-Y\u0022 id=\u0022edit-upload--jj97V7uBGw0--label\u0022 class=\u0022form-item__label\u0022\u003EDatei hinzuf\u00fcgen\u003C\/label\u003E\n[... shortened here ...]",
      "dialogOptions":{
         "dialogClass":"media-library-widget-modal",
         "title":"Medien hinzuf\u00fcgen oder ausw\u00e4hlen",
         "height":"75%",
         "width":"75%",
         "modal":true
      }
   }
]

which insteads runs 5 commands:

• settings
• add_css
• insert
• update_build_id
• openDialog

but misses

• closeDialog

Both times the request is the same!
The only difference between each call is the form_build_id, which I guess is expected!

(Sorry for the noise here, but I'm trying to document all the checks and steps for others to hook in here fur further investigations):

I digged deeper and had a look where the openDialog command comes from and debugging shows that for example when using the media library widget, the open_button #ajax callback is triggered in case of the racecondition:

// Add a button that will load the Media library in a modal using AJAX.
    $element['open_button'] = [
      '#type' => 'button',
      '#value' => $this->t('Add media'),
      '#name' => $field_name . '-media-library-open-button' . $id_suffix,
      '#attributes' => [
        'class' => [
          'js-media-library-open-button',
        ],
      ],
      '#media_library_state' => $state,
      '#ajax' => [
        'callback' => [static::class, 'openMediaLibrary'],
        'progress' => [
          'type' => 'throbber',
          'message' => $this->t('Opening media library.'),
        ],
        // The AJAX system automatically moves focus to the first tabbable
        // element of the modal, so we need to disable refocus on the button.
        'disable-refocus' => TRUE,
      ],
      // Allow the media library to be opened even if there are form errors.
      '#limit_validation_errors' => [],
    ];

so that MediaLibraryWidget::openMediaLibrary() is being executed. As far as I can tell (if ajax didn't kill my debugging event listeners) there is no UI Event on the trigger, so that this seems to be wrongly detected server-side.

I backtraced the call triggered from the "Modal close / cancel" in MediaLibraryWidget::openMediaLibrary() and had a look at the request handled by the kernel.
As you can see the request looks like expected, but the "query" contains the unexpected media library call:

The Media Library Widget was NEVER CLICKED! So where can that part come from?

Searched for further issues which MIGHT be related and found: #3066447: [random test failure] Random failures building media library form after uploading image (WidgetUploadTest) which is far from being clearly related, but both have some things in common, so I think it would make sense to check that?

Anyway, we shouldn't forget that using Drupal 8 + Entity Browser Widget had the same issue as Media Library Widget, but perhaps they're both simply based on the same #ajax or base class logic.

I'm at the end of my latin here... (no idea if that DE term exists in English ;D) we need Core Maintainers look at this.

I debugged it as well. And what I saw is that the triggering element was not found.

So you submit a form with the triggering element information. In the form handling it searches for the element that was triggered the submit. But it was not found.

What then happens is dat het searches for another button, the first button in the list of possible triggering elements in the form.

FormBuilder->processForm()

     // Form values for programmed form submissions typically do not include a
      // value for the submit button. But without a triggering element, a
      // potentially existing #limit_validation_errors property on the primary
      // submit button is not taken account. Therefore, check whether there is
      // exactly one submit button in the form, and if so, automatically use it
      // as triggering_element.
      $buttons = $form_state->getButtons();
      if ($form_state->isProgrammed() && !$form_state->getTriggeringElement() && count($buttons) == 1) {
        $form_state->setTriggeringElement(reset($buttons));
      }

FormBuilder->DoBuildForm()

      // If a form contains a single textfield, and the ENTER key is pressed
      // within it, Internet Explorer submits the form with no POST data
      // identifying any submit button. Other browsers submit POST data as
      // though the user clicked the first button. Therefore, to be as
      // consistent as we can be across browsers, if no 'triggering_element' has
      // been identified yet, default it to the first button.
      $buttons = $form_state->getButtons();
      if (!$form_state->isProgrammed() && !$form_state->getTriggeringElement() && !empty($buttons)) {
        $form_state->setTriggeringElement($buttons[0]);
      }

In this case when I was debugging, the first button was the media library button. And that is why that is command is being returned.

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 also tested that we can reproduce the issue with Media Library in addition to Entity Browser.

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 and there is also a video recording of the effect.

I feel like this issue should have a higher priority because even though it can be hard to reproduce it breaks the content input and node edit form largely and also results in loss of data when it happens.

EDIT: I used a bit more time in the another project and I was able to reproduce the issue there. Interesting enough in the first project we got reports of the issue after 1 month but the other project has been running several years without reports from users. But the symptoms are the same and it's easiest to reproduce the issue by quickly removing a paragraph and then before the Ajax call is finished you click on collapse.

The first project is using Gin, Media library and Entity Browser. The second project is using Claro and Media library without Entity Browser even being installed.

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 #3495881: Firefox retains form_build_id on form reloads, causing old form cache entry to be used and creating weird behavior for the Media Library widget which I think might be related to this.

I just ran into this issue while working at #2772279: Seamless entity reference autocomplete integration.

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 #2772279: Seamless entity reference autocomplete integration (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.

Seems we ran into this with nested paragraphs (drupal 10.5).

When collapsing or editing a nested paragraph Drupal randomly opens the media library instead.

Sometimes it also adds some random paragraph (that shouldn't even exist as a nested option) into the parent paragraph.

Easiest way to reproduce this has been to open and close and edit the nested paragraphs fast, but this has happened even when editing in a reasonable pace.

A possible solution can be found in #3617898: Form cache is deleted after a submission that never actually executed (e.g. an Ajax-only button), stranding the form's cached state and #3617904: A nested entity form's field widget calling $form_state->setCached(FALSE) unintentionally disables caching for the parent form.

When Core cannot identify the clicked Ajax button, it no longer blindly uses the first button. It uses the button whose unique name was posted with the request. Only if that name is missing or used more than once does it still fall back to the first button.

Can we get a test case showing the problem please.

Also summary needs to include what the proposed solution is.

Also was #34 tested if it fixes the issue?

I tested the patch from #34 against this issue. It does not fix it: without the additional change in FormBuilder::doBuildForm(), Drupal still falls back to the first button, so the wrong triggering element is used.

Test coverage is now in place. Ran the test-only test and it fails on the new test coverage.