Entity browser edit does not display messages

I also noticed #2644210: Entity label/thumbnail is not updated after edit the other day.

This may be because we use page--entity-browser--iframe.html.twig for modal too. And we are missing messages there.

Edit dialog is using different template I assume.

This was fixed as part of #2658688: Messages are not displayed in iFrame and Modal displays. Feel free to re-open if I'm wrong.

Hi!

this is a valid bug, because the ajax command isn't using the template "page--entity-browser--iframe.html.twig", so the messages aren't being passed to the form trough the ajax response using new OpenDialogCommand( .... ).

After the submit it never passes into the preprocess functions which are being created from the patch in #2658688: Messages are not displayed in iFrame and Modal displays, so didn't fix the problem.
From what I could debug, the errors are in present in form_state, but they are never catched toward the response, maybe the path to the element isn't right: $form_state['#errors'][0] = ['image_crop][crop_wrapper][news_wide][crop_container][values][width'] => [ .... ]

I guess, in this case we should pass the status messages using ajax commands or attaching into the form.
Maybe this issue #77245: Provide a common API for displaying JavaScript messages could be the solution, but it's still WIP and it won't be commited till 8.4.x version.

Help? :)

I was wondering, that this behavior, not rendering the messages in the AJAX response, is still open or nor noticed form more people.

I have not a solution/patch yet, but just tried to render it in the modal:

Hopefully I will find some time to have a deeper look in it.

#9 actually works.
Provided more accurate approach based on implemented based on #9

#9 is very good and #12 too.

But there too maybe messages if the dialog gets closed (hitting save). These messages are still "lost".

Providing the following patch that integrates #12 and adds (optionally) messages when hitting save in the edit dialog, by providing the messages in a separate modal window. Didn't find another good solution for this as it seems difficult to "correspond" with the "outer" part and attach the messages somewhere where they are surely in the viewport and don't persist in the UI for longer (removed the Novice tag, since this does not seem really a fruitful task for a novice).

The setting can be controlled via the Field Wigdet as maybe not everyone may want to use it.

Rerolled this patch for the 2.x branch.
Also removed the setting to show messages and in stead made it so they always show as that should be expected behaviour in my opinion.

#17 applied to 9.3.x and seems to work as advertised.

Latest release invalidates #17 - rerolled for 8.x-2.9.

Modified patch to display error messages only on the entity browser popup.

Rebased MR

I have removed ajax response which return on closing the model.
We are getting success message in a new popup once we save the entity and here contributor require extra effort to close the popup having success message. We are already getting error messages in a same popup hence as per my opinion to show extra popup for success message seems bad UX.

Any different suggestions or solutions are most welcome.

I had a look at the conversation above. It is better to provide widget setting to control the behavior.
I have rerolled the patch #15

re-roll patch #23 according to the latest code changes.

Re-roll patch #24 for 2.x

Claude Code said, regarding patch #25 (since MR!8 is closed):

Assessment — Reasonable idea, some issues:

1. FileBrowserWidget is missing the feature. It extends EntityReferenceBrowserWidget but overrides defaultSettings() and the edit button rendering. The schema is added for entity_browser_file but the widget class itself never reads or passes show_messages. The setting would appear in the config form (inherited), but the edit button's AJAX query wouldn't include it. This is an incomplete implementation — either it needs to be wired up in FileBrowserWidget too, or the schema addition for entity_browser_file is premature.
2. The pre-submit form path also adds status_messages (lines 77-80 in the controller patch) with #access gated on $this->messenger()->all(). This is unconditional — it doesn't check show_messages — so every edit modal will get a messages element regardless of the setting. This is probably harmless (access is FALSE when no messages), but it's inconsistent with the post-submit path which does check the flag.
3. Passing a setting via query string (show_messages as a GET parameter) means it's user-controllable. It's low-risk since it only controls whether a messages modal appears, but it's a leaky abstraction — a widget display setting shouldn't be a URL parameter. A cleaner approach might store it in the form state or use drupalSettings.
4. entity_browser_form_alter blindly passes show_messages from the request query. If show_messages is NULL (not set), it'll pass NULL into the query array, which is messy but not harmful.
5. UX concern: Opening a second modal (#eb-messages-modal) just to show "Entity saved" after the edit modal closes is somewhat jarring. The user has to dismiss two modals. An inline message or a transient notification might be smoother.
6. No test coverage for the new setting or the message display behavior.

Summary: The core idea (surfacing swallowed messages) solves a real problem, but the implementation has gaps — particularly the missing FileBrowserWidget wiring and the query-string approach. Needs another pass before merging.

Needs rebase