I'm trying to load a view with exposed filters (ajax enabled) inside a modal window (ctools).
The first time when I open the modal windows, the exposed filters works ok, but if I close the modal and open again the exposed filters doesn't work anymore.

When I try to filter the second time I get the following error in Chrome console

Uncaught TypeError: Cannot read property 'top' of null ajax_view.js:131
Drupal.ajax.commands.viewsScrollTop ajax_view.js:131
Drupal.ajax.success ajax.js:400
ajax.options.success ajax.js:164
c.success jquery.form.js:11
f.resolveWith jquery.min.js:16
v jquery.min.js:16
c jquery.min.js:16

I'm using

function mymodule_modal_add($js = NULL) {
  if ($js) {
    $output = views_embed_view('add_car');
    ctools_modal_render(t('Add car'), $output);
  } else {


Members fund testing for the Drupal project. Drupal Association Learn more


mstef’s picture

I'm getting this in some very specific conditions..not using modal windows. It's actually a result from this issue for Quick tabs (#1864800: Ability to force AJAX fetch of tab content every time a tab is toggled). Not sure what is causing it though.

mstef’s picture

I believe it has something to do with this: http://drupal.org/node/1864800#comment-6861108

After reloading a View via an AJAX call, the DOM ID in the JS settings aren't cleared. So it's using a selector that no longer exists because the settings contain old data.

dawehner’s picture

Just wondering whether this could be a duplicate of the other issue?

mstef’s picture

Well the other issue I linked to has to do with the Quicktabs module. I was working on a patch and I came across this issue/bug with Views. I think I'm going to open a new issue with View and link around to all the semi-related issues.

mstef’s picture

Yea like you said, I think this is actually happening after a filter submit (or sometime, only after numerous filter submits). Something seems to be causing it to return a different DOM ID.

mstef’s picture

klaasvw’s picture

Version: 7.x-3.5 » 7.x-3.x-dev
Issue summary: View changes
Status: Active » Needs review
3.88 KB
PASSED: [[SimpleTest]]: [MySQL] 1,658 pass(es). View

I encountered the same issue when using exposed filters multiple times with the entityreference_view_widget module.

The issue is caused by launching multiple ajax instances of a view (in this case with a ctools modal window), which will append a JS setting for each view DOM ID. If the modal window is closed the DOM element doesn't exist anymore, causing a JS error.

This can be fixed by checking if the DOM element actually exists before attaching events to it.

ewandrews’s picture

I had this same issue and patch in #7 solved the problem. Thanks!

mike.davis’s picture

Status: Needs review » Reviewed & tested by the community

I was having the same issue and patch #7 fixed it for me too. Thanks.

rt3me’s picture

I am getting the same error using Better Exposed Filters with views with ajax enabled. When I apply the patch the view works again but it appears to be loading the entire page again rather than using ajax. The functionality seems the same as when you set BEF to automatically resubmit when the exposed filter is changed. Could there some sort of fallback happening here and the ajax functionality is simply being removed by adding the conditional in the patch? I am using views 7.x-3.7.

interdruper’s picture

#7 fixed it for me too, particularly using Entityreference View Widget module and exposed filters inside its modal dialogs.

boyan.borisov’s picture

I had the same issue with views 7.x-3.8 but it seems that the issue was fixed in the next commit.

commit 710a5368c0f71100aaa51de01695d5beb11b5e8b
Author: Earl Miles
Date: Thu May 29 13:27:56 2014 -0700
Use a safer way of finding the exposed form.

interdruper’s picture

Status: Reviewed & tested by the community » Fixed

Yes, commit mentioned by Boyan seems to fix it (with much less code), so we can close the issue with the current release of Views (3.8)

jsacksick’s picture

Status: Fixed » Active

In fact, the commit mentioned in #7 broke Entity Reference Views widget, because the view-filters div is not rendered inside the view, the $exposed variable is wiped in a preprocess_views_view in order to be rendered above the form embedded into the modal to avoid conflicts.

interdruper’s picture

Status: Active » Needs work

@jsacksick, I have in production several Entity Reference Views widgets with exposed filters, running smoothly under Views 3.8 and ERV 7.x-2.0-beta3+2-dev. Please, let us know additional info and/or how to reproduce the problem you have found.

jsacksick’s picture

@interdruper : the commit mentioned is not included in the 3.8 version, try to switch to the dev version and you'll see.

interdruper’s picture

You are right @jsacksick, that commit breaks Entity Reference Views modal forms, Ajax error is returned after submission.

Anyway I cannot reproduce now the original issue with my current configuration (Views 3.8 recommended release and ERV 7.x-2.0-beta3+2-dev), dialogs keep running fine after reopenings, may be the issue in my case is hidden by other reasons.

Patch #7 fix the problem with ERV in your tests? (it did in my original tests...) If so, we should return back the patch #7 to RTBC state, and report the issue with the recent views patch.

jsacksick’s picture

I haven't tested the patch in #7, did you try using the dev version of views? (to reproduce the issue)

joelpittet’s picture

Status: Needs work » Needs review
585 bytes
None View

I think this line needs to be reverted because it does fix ERV.

The exposed filters are not inside the this.$view so it will never find them.

steve.stotter’s picture

3.8 KB
None View

I had the same problem with this error, but with views rendered within blocks on a page. Weird as never come across this before even though I've been doing exposed filters with views blocks for some time.

I was on version 3.8, and agree that the patch included in #7 works great! However, I noticed that the commit in #12 was in the dev version which, after updating to dev, fixed my problem too. I do agree with @joelpittet & @interdruper though that if this already committed fix breaks something else (ERV), then it should probably be reverted and/or reworked.

With that in mind, I've re-rolled the patch provided in #7 by @klaasvw for the dev version. Call it a double fix for now, until the previous fix is reverted. Seems to work great for me!

It's not a big patch, it is mostly whitespace and as @klaasvw mentioned, it just checks the DOM element actually exists first.

@joelpittet - can you open a new issue for the bug you're experiencing and submit your patch there? Cheers.

alesr’s picture

4.15 KB
None View

Patch #20 didn't apply for me on Views 7.x-3.x-dev.
Here's a re-roll.

joelpittet’s picture

@steve.stotter it's from this issue, that's why I put it here... It's to revert part of this commit in #12

Mikhail K.’s picture

I can confirm #19:
this.$exposed_form = this.$view.children('.view-filters').children('form');
from #7 breaks ajax exposed form
And now it's in Views 7.x-3.10, so this patch must be reverted.

rockaholiciam’s picture

I can confirm that the exposed form ajax functionality breaks after I updated to 3.10 from 3.8.

Mikhail K.’s picture

Priority: Normal » Major
zuernBernhard’s picture

Patch from #21 works well here ! Thank you!

gregori.goossens’s picture

I use Entity Reference View Widget since i update to Views 3.10, exposed filter in ctools modal failed due to Use a safer way of finding the exposed form..
I'm fact, i used 7.x-2.0-rc2 version of Entity Reference View Widget , and this version not set any main view div.
It seems the last version resolve issue 7.x-2.0-rc6, and now a main div with .view-dom-id-XXX is define, and the above mentioned commit work fine.

Summary : works fine for me with :
Views 7.x-3.10
Ctools 7.x-1.7
Entity Reference View Widget 7.x-2.0-rc6

joelpittet’s picture

579 bytes
None View

Re-posting #19

+++ b/js/ajax_view.js
@@ -57,7 +57,7 @@ Drupal.views.ajaxView = function(settings) {
-  this.$exposed_form = this.$view.children('.view-filters').children('form');
+  this.$exposed_form = $('form#views-exposed-form-'+ settings.view_name.replace(/_/g, '-') + '-' + settings.view_display_id.replace(/_/g, '-'));

The reason this needs to be reverted is because when you expose a filter in a block it's no longer inside the div of the view and can be placed anywhere on the page.

Though I like the intent behind the commit (removing specific selectors is usually a good thing) it just doesn't work in this case :(

I changed one thing to make the jQuery faster by using just the ID instead of form#ID.

lauriii’s picture

Status: Needs review » Reviewed & tested by the community

  • dawehner committed 96a54e0 on 7.x-3.x authored by joelpittet
    Issue #1809958 by joelpittet, steve.stotter, alesr, klaasvw: Views with...
dawehner’s picture

I totally agree that the "fix" introduced by merlinofchaos made the situation worse, so let's fix that. In case somebody figures out what earl tried to fix, we could do it on top of it.

PS: Does anyone know what the situation in D8 regarding the patch is?

dawehner’s picture

Status: Reviewed & tested by the community » Fixed


Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Harley Bussell’s picture

I've found a problem with the current patch committed with 96a54e0.

We where displaying 2 copies of the same view with the same display id on a page and found the exposed form for the second form was not working.
The issue is that the jQuery selector used in 96a54e0 assumes the view name and display id is unique on the page. My patch [fix-views-duplicate-display-id-1809958.patch] just adds the view as the context for the jQuery selector which fixes the problem.

samuel.mortenson’s picture

Status: Closed (fixed) » Needs review

Moving back to Needs review, it sounds like the last patch introduced new bugs.

J-Lee’s picture

I've got the error "cannot read property 'top' of null" when using exposed filters.
Patch #34 worked for me, but I have only one view at the page.

pefferen’s picture

I had trouble applying the patch in #34, made a new one that dit work for me. The proposed solution in #34 for adding the view as context to the jquery selector worked for me.

joelpittet’s picture

Status: Needs review » Needs work

@Harley Bussell, @pefferen, @J-Lee, and @samuel.mortenson. The $view would refer to the view listing itself. If you expose a form in a block, it can literally be placed anywhere on the page and not inside the $view. It you target the form only inside the $view element you will miss it. I think the troubles you may be having are not related to this, I could be wrong but what makes you think narrowing the selector will help solve this?

My only guess is that you have two exposed forms on the same page with the same ID (bad HTML), likely one behind the modal and one inside the ctools modal. Maybe inspect the HTML on the page this is happening and confirm that is not the case?

Please consider closing this back up and opening a different issue to resolve these other problems.

samuel.mortenson’s picture

@joelpittet Narrowing the selector helps solve the problem as it scopes the following logic to the relevant exposed form, not the first one returned by the selector. You're right that this is a problem with "bad HTML", but that's a Views problem in that it doesn't expect users to embed the same View with exposed forms multiple times on one page. You're also probably right that adding context would break exposed forms in blocks, so we'll need to come up a new fix.

joelpittet’s picture

@samuel.mortenson thank you for confirming and narrowing down where the problem is.

I wonder if we can 'tag' the exposed forms with a data attribute or something so it knows what view it's related to? That way it's not ID dependent?

ezeedub’s picture

This is still ID dependent, but adding the dom id to the selector works in the case where I encountered this issue.

I looked in other commits in the 3.12 release but did not find where the dom id is appended to the exposed form element's id attribute, so I'm not sure if this is a general enough solution.

ezeedub’s picture

Status: Needs work » Needs review
samuel.mortenson’s picture

Is this missing the backend code that append the "view_dom_id" to the exposed form's normal ID?

khoatm’s picture

Thanks a lot, it worked for me in FF and Chrome, but it still doesnt work in IE.
Have error message at:
"Drupal.views.ajaxView = function(settings) {
var selector = '.view-dom-id-' + settings.view_dom_id;
this.$view = $(selector);

jadsay’s picture

Applying patch #41 didn't work for me, but #37 works just fine. Scenarios in which patch #41 do not work:

Scenario 1 - Adding Node Pane with panels IPE using the node_pane module:

I'm adding node pane with panels ipe using node_pane module which provide me the ability to select an existing node directly from a list that is built with views and has an exposed filter. I was facing the same with exposed filters after closing and opening the popup a second time .
Patch #37 fixes the issue , #41 doesn't.

Scenario 2 - Adding Views with panels IPE:

This is a side effect of patch #41 since it's not related to views in modal.
I've added two views using panels ipe in a page , both views with exposed filters. With patch #41 , clicking on the submit button of the exposed form do not trigger ajax and reloads the page

JimJS’s picture

#37 work for me. I have 1-page with 3-view panes and 1-exposed filter from one of the panes. The other two panes also have exposed filters that don't need to be included on the page. I believe this is because they share the same "Filter identifier" from the "more" section of the filter.


imshuffling’s picture

#37 Works for me, thanks.

I have 2 exposed input filters using field collection views.


ak55’s picture

#37 works great!
Hope this is going to be merged into the next version of Views.

A----’s picture

Regarding #41, @ezeedub, check your views.module:2046, it probably is:

$form['#id'] = drupal_clean_css_identifier('views_exposed_form-' . check_plain($view->name) . '-' . check_plain($display->id) . '-' . check_plain($view->dom_id));

which is neither the 7.x-3.14 or 7.x-3.x one.
I had the same issue with the version distributed with the latest Open Atrium (7.x-2.64) distribution.

That patch would make sense, form ids would be unique even if multiple instances of the same view were to be included in the same page (and why not?).

In fact, the id could be even shorter using by using simply the dom_id. I'm not sure of the implications but since the id has to change to be unique, well, let's go for it.

#37 doesn't make sense though, IDs should be unique.


  1. 7.x-3.14 works in most cases;
  2. if you have two instances of the same view, #34 or #37 would not be a proper fix;
  3. rely on dom_id for that purpose. You can use #41 but you will also have to patch views.module:2046, or try attached patch.
A----’s picture

OK, Additional information here. Seems that #41 fix has been used in conjunction with this patch:

My patch might not be a good idea if you haven't applied that one.

I'm linking the issue 1735096, which would be a better place to discuss the multiple instances issue.

alimc29’s picture

I have also run into this issue discussed in comments #34 and down.

For now, I've successfully applied the patch from #37, per other's feedback.

I second ak55's comment here - I'm wondering if there's any work on getting this fix committed into the module itself so that we don't have to keep track of the need for this patch in future updates.

Thanks for the work on these fixes!

cilefen’s picture

cilefen’s picture

cilefen’s picture

I am affected by #1877238: Views caching cannot be combined with Ajax on cached pages if the Ajax rendered data or query are cached.

fox_01’s picture

#37 works for me
#41 does not work for me

loparr’s picture

#37 works for mee as well

Martin.’s picture

Be careful when considering those patches as actual fixes. I don't know for sure if this is related to this but I am fairly confident it is. For some reason in views_plugin_exposed_form.inc in method render_exposed_form() line 161 form is built with drupal_build_form() which calls out drupal_reset_static('drupal_html_id') and this means that every element which put together after this views is called could possibly get wrong html ID (read reserved). The bug it generates isn't obvious until you have some ajax elements, like ajax form, which rely on the unique html id. For example my case was that all the forms that were rendered after the view that had exposed form in block and ajax enabled got wrong html id and the forms stopped working correctly.

I think this issue cant be considered as fixed before the resetting of drupal_html_id static variable is avoided during exposed form rendering.

By looking at the code in drupal_build_form() I have come to conclusion that avoiding the drupal_static_reset('drupal_html_id'); which is actually called out at drupal_process_form is inevitable. Can anyone confirm.

Long story short:
views exposed form + exposed in block + ajax results in drupal_static_reset('drupal_html_id'); and will therefor potentially break other forms on the page.

PS. My view is also a block

cilefen’s picture

Note this patch on a similar (possible duplicate) issue: https://www.drupal.org/node/1877238#comment-11562657

usta’s picture

Are there any reasons for not committing #37?

Without #37 patch 96a54e0 introduces the very bugs it set out to fix (I can *no longer* use views in a ctools modal more than once).

joelpittet’s picture

@usta read why #37 is not correct in my response #38 and #40. It breaks exposed filters when placed in a block somewhere else on the page.

danielb’s picture


codefactory’s picture

#49 seems to work for me. I had the issue with linkit_picker while attached to wyiswg. linkit_picker module attaches a view with form alter to the linkit form