When browsing an Ajax view, many Drupal.Ajax are created for the refresh feature. Those objects are not cleaned up.

Need to either add some code to clean them up or prevent several objects from being created.

Comments

nod_ created an issue. See original summary.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ChristianAdamski’s picture

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

ChristianAdamski’s picture

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.

ChristianAdamski’s picture

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.

ChristianAdamski’s picture

Status: Active » Needs review
FileSize
521 bytes

Let's see if that change breaks any tests.

ChristianAdamski’s picture

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

slasher13’s picture

Status: Needs review » Reviewed & tested by the community

works for me

nod_’s picture

Status: Reviewed & tested by the community » Needs work

Why do you have this condition?

    if (this.$view.length === 0) {
      return;
    }

ajaxView is a constructor, returning early makes a useless object, and seems out of scope for this issue.

Also when changning pages, I would expect the refresh object to be updated to use the new current page the view is at. Looks like we'd refresh the first page only, not the current one.

ChristianAdamski’s picture

@_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.

Aurif3x’s picture

@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.

Vagelis’s picture

Patch #7 works for me.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joshtaylor’s picture

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