Problem/Motivation

In the media widget Views (both grid and table displays), I tried enabling the reset button option in the exposed form settings as this gives a better UX to content editors.

While enabling the option does show the reset button in the widget, clicking it redirects to /admin/content/media-widget/image?name=&sort_by=created&op=Reset with an "Access Denied" error.

I'm not sure if the root cause is the similar issue I found: https://www.drupal.org/project/drupal/issues/3346820 or if the media library widget has a bug itself causing the issue.

Steps to reproduce

  1. Go to: /admin/structure/views/view/media_library/edit/widget and enable the Reset button option in the exposed form settings.
  2. Add a node or other entity that has a media reference field, with the form mode set to use the media library widget.
  3. In the media library widget filter the results in some way, this should then show the reset button.
  4. Click the reset button to reset the form filter options.
  5. You should be redirected to /admin/content/media-widget/image?name=&sort_by=created&op=Reset with an "Access Denied" error.

Proposed resolution

Fix bug so that the reset button on media library widget form correctly resets the form.

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Issue fork drupal-3376978

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

PCate created an issue. See original summary.

carolpettirossi’s picture

StatusFileSize
new5.27 MB

I'm facing the exact same issue.

Screencast showing the access denied page

anybody’s picture

Version: 10.1.x-dev » 11.x-dev
Priority: Normal » Major

Same issue here! It's even worse, all the values intered in the form behind the modal are then lost, as the page reloads!
Presumably this is kind of duplicate of this issue #3346820: On views with AJAX enabled, exposed filter "reset" causes (non-ajax) page load, but I think we should keep both open as this one shows how critical the result of the page reload can be!

Aditi Saraf made their first commit to this issue’s fork.

bkosborne’s picture

Ran into this myself after adding the missing "reset" button for the filters. It's too bad, as it would really improve the UX if we could add the button, especially to reset the text filter.

aaron.ferris’s picture

I've also recently come across this. We've hidden the button if it can't be used in certain scenarios.

I wonder how complex the issues with the form reset are based on the comment in https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views... probably not trivial.

    // Exclude the reset buttons so no AJAX behaviors are bound. Many things
    // break during the form reset phase if using AJAX.
adwivedi008’s picture

@aaron.ferris I think hiding the reset button won't work.

In certain cases, we can hide it but from the user's perspective it would be not very clear if the button is visible at certain places and hidden from certain places

aaron.ferris’s picture

@adwivedi008 - indeed, its not perfect, but ultimately preferable to a button that exists which completely breaks the journey.

joshua.boltz’s picture

I get it, this seems complicated, but seems like it lost traction. Has this moved into another issue?

anushrikumari’s picture

StatusFileSize
new993.81 KB

I was reviewing the behaviour in the modal and turns out that the reset does not trigger any AJAX, as it is happening for the Apply Filter button.
This issue is similar to the https://www.drupal.org/project/drupal/issues/3346820

anybody’s picture

Today we saw that now even the "Filter" button isn't AJAXified anymore in modals, and it's moved to the modal actions!

So currently the whole media selection is broken. Any idea?

Update: This patch was the reason: #2897377: $form['#attributes']['data-drupal-selector'] is set to a random value so can't be used for its intended purpose

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.