- π©πͺGermany rgpublic DΓΌsseldorf π©πͺ πͺπΊ
Um, why was this closed? My experience:
1) The problem mentioned in #3133257 was resolved as a duplicate of this one but is still valid
2) It happens not only with BEF but even with normal exposed filters
3) "Automatically load content" doesn't even have to be checkedTo reproduce:
1) Create a view with exposed filter and the usual "Filter/Submit" button
2) Scroll down, click on "Load more". Wait for some additional view rows to be loaded
3) Open the Debug console's network manager, optionally filter just for XHR requests
4) Optionally change some filters and click again on "Filter/Submit". See how every request is now executed twice, because the event has been attached more than once. - Status changed to Active
8 months ago 12:34pm 24 October 2023 - π©πͺGermany Anybody Porta Westfalica
Thanks @rgpublic! So let's reopen this one.
Any ideas on a fix? You tested this with 2.0.x I guess?
- π©πͺGermany rgpublic DΓΌsseldorf π©πͺ πͺπΊ
@Anybody: Thank you for looking into this. I've just pushed a commit to the issue fork - hope it's correct. Still need to get used a bit to the new issue fork system. As you can see, I'd suggest removing the "once.remove('exposed-form', view.$exposed_form);" line altogether. Hope it doesn't cause any other problems. My line of reasoning was the same as detailed in #3133257: This module doesn't replace the exposed form. It only replaces the view's body. Therefore it shouldn't remove the once flag because it will subsequently cause a second/third/etc event handler to be reattached.
- @anybody opened merge request.
- Status changed to Needs work
8 months ago 7:19am 26 October 2023 - π©πͺGermany Anybody Porta Westfalica
Thanks @rgpublic! This definitely needs tests, so that we can be sure it works as expected in all situations now and in the future.
Removing these intended lines is risky and even if it might be correct, we have to be sure it's always correct.
Could you please take the time to add the tests for this? Then I'd be happy to review and merge the fix. I hope you understand, why it is so important to have test coverage for this module. It's breaking again and again and we need to get out of that loop in all issues. - π¨πSwitzerland pvbergen
I've stumbled upon this issue, experiencing multiple loads on after scrolling down using infinite scrolls. I investigated and found the same reasoning as rgpublic. Each ajax load adds another handler to the submit button.
I can confirm that removing the line "once.remove('exposed-form', view.$exposed_form);" resolves this issue (Commit: https://git.drupalcode.org/issue/views_infinite_scroll-3035601/-/commit/...)
For test coverage and next steps:
- I will do user testing on our project, maybe I can try to find some test to cover that automatically.
- It might also be an option to make this configurable. I can imagine both use cases, either reloading the same number of pages on filter change or just loading the first page. In this case we could make reloading all pages the default behavior, which makes this change transparent for existing websites.