If you follow the standard steps to have an entity browser with two tabs which are
1. an upload widget and
2. a view to select entities

If you have a reset option on the exposed filters when you click on it to reset the view it instead loads the upload tab. I'd expect the reset button to simply reset the view.

CommentFileSizeAuthor
#9 interdiff_7-9.txt830 bytesmaximpodorov
#9 entity_browser-fix-for-reset-2939481-9.patch1.42 KBmaximpodorov
#7 entity_browser-fix-for-reset-2939481-7-8.6.patch1.31 KBhawkeye.twolf
#4 entity_browser-fix-for-reset-2939481-4-8.5.patch803 bytesWeilinggu

Comments

vaccinemedia created an issue. See original summary.

samuel.mortenson’s picture

samuel.mortenson
he/him
Primary language English
commented
Category: Support request » Bug report
johnpitcairn’s picture

johnpitcairn commented

Reproducible here. Rats.

Weilinggu’s picture

Weilinggu commented
StatusFileSize
new entity_browser-fix-for-reset-2939481-4-8.5.patch803 bytes

Noticed that this only happens in Tabs widget selector. Added a check so when user click reset, it wouldn't trigger tab switching.
Logic: If form_state has "op" input, it means it's coming from view, there is no reason to trigger submit in Tabs.php

Weilinggu’s picture

Weilinggu commented
Status: Active » Needs review
marie.pinet’s picture

marie.pinet commented
Status: Needs review » Needs work

Hi,

I have a same problem in my project.

I have "2 types" of entity browser :

  • type 1: with only a entity view,
  • type 2: with an entity view in first and one or more entity form.

Without this patch, when I click on the reset button :

  • type 1 => the modal is closed,
  • type 2 => the active tab changed.

With this patch, when I click on the reset button :

  • type 1 => no change, the modal is closed,
  • type 2 => the active tab no changed.

When I make a breakpoint in the submit function patched, I can see that the trigger element is bad.
For examples :

  • type 1: the trigger is the entity browser submit button
  • type 2: the trigger is the next tab

But I don't have find where is the problem.

Thanks for your help.

Marie

hawkeye.twolf’s picture

hawkeye.twolf
they/them or he/him
Primary language English
Location ᏙᎩᏯᏍᏗ Unalatogiyasdi, Tsalaguwetiyi (Cherokee country)
commented
Status: Needs work » Needs review
StatusFileSize
new entity_browser-fix-for-reset-2939481-7-8.6.patch1.31 KB

New patch attached to fix issues caused by the previous patch when the Views widget was not first in the list of tabs.

maximpodorov’s picture

maximpodorov commented

Reset button can have translated or even modified label.

maximpodorov’s picture

maximpodorov commented
StatusFileSize
new entity_browser-fix-for-reset-2939481-9.patch1.42 KB
new interdiff_7-9.txt830 bytes

This patch adds checking against the translated "Reset" string.

fernly’s picture

fernly commented

Patches not working against the stable 8.x-2.4 release.

teknorah’s picture

teknorah
she/her/hers
Location Mokena, IL, US
commented
Status: Needs review » Reviewed & tested by the community

Successfully applied patch against 8.x-2.5 & 8.x-2.6 release.

Can we get this in the next release, please?

nicolas bouteille’s picture

nicolas bouteille commented

Works for us too on 8.x-2.6 with modal + single widget. Thanks for the patch!
+1 RTBC

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

The reset button string is configurable, getTriggeringElement() might allow to identify that more easily?

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Reviewed & tested by the community » Needs work
plopesc’s picture

plopesc
he/him
Primary language Spanish
commented

Hello,

I've been digging into this one and it seems that $form_state->getTriggeringElement() is not returning the Reset button, but the tab selector button added in WidgetSelectorBase::getForm().

Apparently, when clicking on the "Reset" button, the form being submitted is the parent one and to the views exposed one.

I have the feeling that will be necessary to add some JS in entity_browser.view.js to capture the Reset button event and proceed accordingly.

Another option would be to load the view in EntityBrowserForm::submitForm() and compare the button value with the value stored in the view. However, that would open the door to inconsistencies with other modules like BEF or custom exposed form plugins.

What do you think?

pawelgorski87’s picture

pawelgorski87 commented

Morning,
I had 2 tabs, and reset button always setup 1st one after reload page/alax.
Patch #9 https://www.drupal.org/files/issues/2020-01-28/entity_browser-fix-for-re...
works in my case.
Thank you. Drupal 10.4.6 PHP 8.3.16

kumkum29’s picture

kumkum29 commented

Hello,

As mentioned by pawelgorski87, on Drupal 10.4.6 / PHP 8.2.27, when I click the reset button, I am redirected to the second tab.
With patch #9, this undesired behavior is resolved.

Do you plan to include this patch in the next version of the module? (I can't patch a website in production.)