Ajax views leave obsolete Drupal.Ajax instances

Hey, let's see if I'm having the same issue.

Steps to reproduce:
- create a page view of nodes
- use fields and just the title
- expose a filter, for me it's the node type (article and page)
- enable ajax
- create an attachment view - it can display the same things again
- let the attachment inherit the exposed filter
- now trigger the exposed form a couple times

I notice two things:
- Drupal.ajax() is triggered 2 times more with every button trigger, it starts with 2 calls and then each time goes up by 2
- for every AJAX refresh, a new similar entry in drupalSettings.views.ajaxViews and Drupal.views.instances is created. Each of these is only for the attachment view and gets a new DOM ID. So after 10 triggers, you will have one entry for page_1 and 10 with varying dom_ids for attachment_1

I'm still debugging through this. My current find is that the expired instances are not removed, because after the Ajax load they have no "element" defined, which in turn is ignored by Drupal.ajax.expired()

No idea is this is relevant though.

I can confirm that Drupal.views.ajaxView() simply assumes that whatever setting is handed to it also corresponds to an element and just uses the jQuery(selector) result as a given, with actually checking, if that result actually contains anything.

When adding a bailing out function for element not present at the beginning of that function, everything still works fine for me.

Let's see if that change breaks any tests.

This patch additionally makes sure the RefreshView is only attached once per view. This is already happening before for the exposed form handling and the pager links, but not the manual refresh.

The patch is based on the linked issue #2415027

works for me

@_nod, I agree that this is out of scope for this issue. It's still a problem though. Entries are created for views that are simply not there.

If you confirm that, I would create a new issue.

The issue with the obsolete instances seems to come from the way the SettingsCommand works. It will simply extend the existing settings list of instances. And I do not see any ability to replace instead of extend.

@nod_ @ChristianAdamski, for what it's worth, that condition resolves an error I'm having when using an exposed filter: #2797587-4: Uncaught TypeError: Cannot read property 'top' of undefined in ajax_views.js line no 200

If I understand correctly, this condition is simply masking a deeper problem. But, I know next to nothing about this code and can't tell how to fix it.

Patch #7 works for me.

I'm also seeing this happen on an exposed filter in a view, and patch #7 fixes it.

#7 works for me as well

I have this problem on 8.3.6, with Thunder profile.
I added this path:

        "patches": {
            "drupal/core": {
                "Ajax views leave obsolete Drupal.Ajax instances": "https://www.drupal.org/files/issues/2771361-7-do-not-attach-ajax-to-non-present-views.patch"
            }
        },

but it still have problem with this error.

raven.js:367 Uncaught TypeError: Cannot read property 'top' of undefined
    at adjustIfNestedAndOverlapping (contextual.js?v=8.3.6:116)
    at initContextual (contextual.js?v=8.3.6:92)
    at contextual.js?v=8.3.6:205
    at Function.m.each.m.forEach (underscore.js:158)
    at Object.success (contextual.js?v=8.3.6:189)
    at i (jquery.min.js?v=2.2.4:2)
    at Object.fireWith [as resolveWith] (jquery.min.js?v=2.2.4:2)
    at z (jquery.min.js?v=2.2.4:4)
    at XMLHttpRequest.<anonymous> (jquery.min.js?v=2.2.4:4)
    at XMLHttpRequest.d (raven.js:363)

(Raven.js is error handler: https://www.drupal.org/project/raven)

#7 works for me as well, ran into this bug after upgrading from 8.3.6 to 8.3.7

Patch #7 works for me - Drupal 8.3.7.

Here is a reroll for Drupal 8.5

Patch #7 works for me as well - Drupal 8.4.5 Thanks!

As this is a 8.6.x patch, the javascript should not be modified directly

for ajax_view.js there is an equivalent ajax_view.es6.js file.

There is a change record which gives instructions on how to setup a es6 build environment.

Here is the change record.

https://www.drupal.org/node/2815083

Rerolled according ES6

the smallest of changes

the AirBnB coding standard which we have adopted replaces single line functions of the form

function() {
  foo('hello');
}

with equivalent code of this form

() =>  foo('hello')

It would be too big an issue to replace all examples in code globally.... but for new code I want to follow the coding standard.

Would be nice to have an automated test for this.

@hiten2112 Hi,

Could you explain the interdiff please?

It appears only ajax_view.js has been modified, which is not a file which should be modified directly.

ajax_view.es.js is a file that should be changed and then the automated build process reflects the changes to ajax_view.js

In short interdiffs should see matching pairs of changes, one to ajax_view.es.js and then ajax_view.js

This is a dangerous change, because it is not permanent, the next time the build process runs as part of future issue
then changes to only ajax_view_js will be overwritten.

Any news about this?

I've updated drupal core to 8.8.0, created a simple view with one exposed filter and enabled Ajax from views configuration. I am getting the same error mentioned below in the browser console when ajax is triggering after hitting the submit button.

Uncaught TypeError: Cannot read property 'top' of undefined at Drupal.AjaxCommands.viewsScrollTop

Tried applying the above patches but none of these worked for me. Composer throwing error "Could not apply patch! Skipping.".

I added the following codes in my custom views-view.html.twig file, after that views Ajax started working. Somehow attributes were missing from the custom views-view.html.twig file. The view selector was referring to old dom id instead of the new one generated after page refresh.

{%
  set classes = [
    dom_id ? 'js-view-dom-id-' ~ dom_id,
  ]
%}
<div{{ attributes.addClass(classes) }}>
  {# printed all required variables here #}
</div>

Patch #28 worked for me.

Re-roll for 9.1.x

Patch on #42 fixes the bug on Drupal 9.2.4. Thanks!

#42 works on 9.2.9. Also solves #2986041: Triggering RefreshView on a view is making multiple ajax calls which implements an essentially identical fix.

Can confirm #42 also works on core 9.5.11. I propose this is moved to RTBC.

Patch for 11.x.

Re-rolling patch #42 for D10.

Re-rolling patch #42 for D10. (With missing var _this) added.

Patch for 11.x

As mentioned will need a 11.x MR.

Issue summary should be updated with standard issue template as well.

Previously tagged for tests also.