Content leakage to other blocks when Ajax is enabled

I can confirm similar behavior. One difference is that I can replicate it happening when a user is logged in or anonymous. Here are some basic facts:

1. I had one exposed filter with memory set to on.
2. When you goto the view and it loads the last query, everything is ok.
3. But if you run a second query, it displays the output 2-3 different times in different spots on the page. The container is broken. I get the same behavior in Firefox, IE, and the webkit browsers.

4. If you click the query again, it goes away.
5. Turning off AJAX fixes the problem. I certainly would like to have AJAX running, but I greatly appreciate vacilando identifying a temporary fix.

Drupal 6.16
Views 6.x-1.9

I thought perhaps it had to do with caching, so I turned off Boost and cleared caches. I also turned off the views cache. It didn't fix the problem.

We see this in our environment as well, and we're using the 3.x tree.

It has to do with the way Views addresses its content, using the views-dom-id-# method. Views assigns each piece of content that it intends to reference via Javascript one of these CSS classes, and it maintains a static variable that it increments each time a new piece of content is created. So, on a page, you can have views-dom-id-1 followed by views-dom-id-2, views-dom-id-3, and so on. The problem comes in where you have blocks that you are caching that contain views. Since the block is cached, the views code to assign the unique views-dom-id class is not run, and the block continues to use the views-dom-id that was assigned when the block was cached. This is a recipe for collisions, which is exactly what you (and I) are seeing. The cached views-dom-id class is the same as another views-dom-id that was assigned to another block of content at runtime, so, when the ajax replacement occurs, both blocks are replaced with the new content.

This is not really a minor issue, so I've bumped it back up to normal status and pushed it forward to the current dev tree since the problem still exists.

Based on the way views works, you can't really cache an ajax-enabled view except through a full page cache. If you do that (such as block caching for an ajax-enabled views block), then the necessary Javascript Drupal.settings items are not properly set, because the necessary code isn't run again on subsequent page requests. Even so, there's still the problem of the views-dom-id situation. Personally, I really think that wholesale replacing the old method of addressing the divs with the view name and display ID was a mistake. Instead of replacing that, the views-dom-id class should be *added* as an *additional* method of checking. Doing so would likely take care of most of the people experiencing this problem, because, in many, if not most, cases, the blocks that have the same views-dom-id are not actually the same view and display.

Of course, if we could come up with a more foolproof method of uniquely identifying a block of views content, that would be best. In the meantime, adding back view name and display ID checking will probably take care of the issue for most people. I might try to throw together a patch for this for the 3.x tree.

Also, it's a bit more broad than just the example, so tweaking the title.

Subscribing

I would need some way of reproducing this myself before I can push this to a dev.
Please provide an export/Feature.

Marking as duplicate of #494380: ajax_view.js backward compatibility breaks pagers.

I'll have to go back and see if this is still happening, but, unless some other code has been committed as well to address the problems with the PHP code, the Javascript patch in #494380: ajax_view.js backward compatibility breaks pagers does not fully address the issues I described here. I don't think this should really be considered a duplicate.

If it's not a duplicate, please provide an export of the view that causes this error, and step by step instructions on how to replicate.

We're seemingly having the same issue as mgriego.
Multiple blocks on a page are assigned the same view-dom-id-N class, due to caching.
This breaks Drupal.Views.Ajax.ajaxViewResponse in ajax_view.js.

This is happening to me also. It looks like it happens when you have multiple view blocks on same page, that were not cached during the same request. Since views use static variable to increment dom_id. This can even happen, if we do not cache ajax-driven block, but we cache some other. It is likely, that this two blocks get same ID.

This bug stays in 7.x-3.x also.

I see two solutions. The code, that calculated dom_id looks like this:

<?php
  static $dom_id = 1;
  $vars['dom_id'] = !empty($view->dom_id) ? $view->dom_id : $dom_id++;
  $vars['classes_array'][] = 'view-dom-id-' . $vars['dom_id'];
?>

We could set $view->dom_id on some other place, and take responsibility for this to be unique. In fact it's exactly what I currently do on my sites. I implement hook_views_pre_render(), that overrides dom_id for all views in the system:

<?php
function MYMODULE_views_pre_render(&$view) {
  $view->dom_id = $view->name . '-' . md5(rand());
}
?>

This solution needs custom code, so I believe, that we need to fix this in Views itself. I propose, that we use something other than incremented counter for dom_id. Attached patch does it.

This seems to make sense. Let's hope people don't rely on this class.

So committed to 7.x-3.x
Sadly it doesn't apply to 6.x-3.x, so update status.

Backported to 6.x-3.x with some comment improvements.

we were having this same problem on a v6.2.16 site
this patch fixed our issue.
thanks.

We also had this issue on a 6.x Views 2.x site with AJAX and the dom conflict with a cached view — the patch from #12 resolved for us.

Any hope for for a Views 2.x fix?