I’m working on a site that is currently on drupal/core 10.3.14, and I’ve had an issue with the "Files listing" tab (“View” widget plugin) of the File Entity Browser → in every new Core version since 10.4.0. When I open the entity browser modal and apply a filter with the exposed form after upgrading past 10.4.0, rather than showing the filtered results, the modal resets to the "Upload files" tab. Interestingly, when I open the View associated with the module (files_entity_browser) and apply a filter in the preview, the filter works perfectly.
Since this issue seems to be directly correlated with drupal/core updates, we assume that it appears in locations other than the file entity browser, but we haven’t found any instances of the problem elsewhere on our site.
We’ve narrowed down the issue to the core/assets/vendor/jquery.ui/ui directory. Any help or suggestions would be greatly appreciated.
1. Upgrade to drupal/core 10.4.x or greater
2. Install the
File Entity Browser →
module
3. Manage the form display of an image field in any content type and add the "Entity Browser" widget to it (select "Browser for files (modal)" in the widget settings)
4. Create/edit a node with that image field
5. Open the entity browser in the image field
6. Select the "Files listing" tab
7. Apply a filter (ex. a filename)
When the filter is applied, files that meet the filter’s criteria should appear (shown in screenshot-1.png).
When the filter is applied, the modal resets to the “Upload files” tab (shown in screenshot-2.png).
Active
10.4 ✨
javascript
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I'm encountering a very similar issue after upgrading to Drupal 10.4.x (currently 10.4.5), but in a slightly different setup where each tab in the modal displays a view that includes exposed filters. For this particular setup I use entity_browser module only.
If anyone that can reproduce this would perform a Git bisect operation on a working copy of Drupal Core you would quickly find the commit that changed this behavior, which would go a long way toward solving this.