Views Ajax Filter fails causing a page refresh

Same issue for us also

My guess is that there's something happening that's causing some JS to break. Are there any console errors present right before the page "reloads".

Then you need to step through the AJAX request to pinpoint where this is happening. I don't have the time right now to do this. It would also help if we can pinpoint this on a fresh D8/Drupal Bootstrap install, which will eliminate any "site specific" issues.

I'm having the same problem with a recently set up D8 site using Bootstrap. My Ajax exposed filters cause the page to redirect to the URL of the actual view page. I'm embedding the page display on a different path.

Please see example: http://bryanjiencke.com/snippet

I went through the same steps as glynster. If I switch my theme to anything besides Bootstrap, it starts working.

I'm not familiar enough to walk through the Ajax request -- any help would be greatly appreciated!

I am having similar issue where pagination using ajax works, but not the exposed filters. I have D8.0.3 and Bootstrap 8.x-3.0-beta2. I don't see any error on console or in Recent Log Message. However, i noticed warning message in console from jquery.js line 8561 as following:

it's failed in executing following line

xhr.open( options.type, options.url, options.async, options.username, options.password );

Error message: Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.

Thanks,

I think it's all related to this old issue https://www.drupal.org/node/1692198#comment-6426420 where basically views ajax is expecting an 'input' and bootstrap is providing a 'button' instead.

Haven't started debugging yet, but quick searches and quick glance - seems to be the problem.

Other relevant issue - https://www.drupal.org/node/1551534

Two things. Sorry, on a tight timeline, didn't roll patches, but here is some code that needs to be changed to get it working.
This is with:
Bootstrap 8.x-3.0-beta2
Drupal 8.0.4

1.
In bootstrap, /templates/views-view.html.twig - change

line 41
dom_id ? 'view-dom-id-' ~ dom_id,
to
dom_id ? 'js-view-dom-id-' ~ dom_id,

2.
In core/modules/views/js/ajax_view.js - change

line 117
$('input[type=submit], input[type=image]', this.$exposed_form).each(function (index) {
to
$('input[type=submit], button[type=submit], input[type=image]', this.$exposed_form).each(function (index) {

And that should fix this issue.

Not sure why the views-view.html.twig is 'view-dom-id' instead of 'js-view-dom-id' and if changing that breaks anything else downstream, but I don't think so at this point, but who knows.

Relatively untested, but works for my specific setup atm.

@mikefyfer

https://www.drupal.org/node/2671778#comment-10902938

I noticed this issue when using the views accordion plugin:
stable and classy both uses: dom_id ? 'js-view-dom-id-' ~ dom_id,
but bootstrap uses dom_id ? 'view-dom-id-' ~ dom_id,

This also caused the accordion to not work because it was initialized based on js-view-dom instead of view-dom-id

Would the stability of bootstrap increase if it's based on a base theme? classy or stable?

type: theme
base theme: false

name: 'Bootstrap'
description: 'Built to use Bootstrap, a sleek, intuitive, and powerful front-end framework for faster and easier web development.'
package: 'Bootstrap'

@gcharles this is already fixed in the dev version of bootstrap, so it will be fixed on the next release.

Core has moved to prefixing required css classes for JS with js- (see #2431671).

To the bootstrap maintaners (apologies if you're already considering this):

Stable theme is the cleanest you can have as a base theme, so none of the Drupal's standard classes are in (those are in classy). Only the stuff we didn't have time to clean up are still there, but so are they in core's templates. It's essentially a copy of core's templates when 8.0.0 was released.

So if you want to have a clean slate with bootstrap, I would suggest to base bootstrap on stable rather than no base theme. Core's markup will probably be continued to be cleaned up, so unless you want to keep track of what core does in the near future, having stable be your base theme will give you a more well, stable markup.

That said, and just to be clear, for any template you override from stable, make sure to leave in place any js- prefixed css classes in place, or you'll break js functionality.

Re: stable or classy base theme, absolutely not. Core's implementation of a "stable" base theme is just a fabricated illusion. It will become outdated, restricted and ultimately broken over time. The name "stable" is very misleading and there is actually no gaurentee that this project would work between minor core releases.

Furthermore, any customizations from "stable" would require this project to implement its own template overrides anyway. Instead of complicating matters and relying on a "base theme", I would much rather skip this extraneous step and do it ourselves.

Fwiw, the decision that lead to "stable" did not involve me and it is essentially yet another band-aid for a problem with the theme system itself.

I would recommend reading https://drupalwatchdog.com/blog/2015/8/drupal-should-use-external-front-... (including the comments).

So it appears this is actually a core issue (with the jQuery selectors targeting only input elements). That being said, I think we might be able to extend/override core's JS with our own to "fix" this temporarily. I would strongly recommend creating a complimentary core issue to fix this upstream though.

Hello,

This issue still exists. (version: '8.x-3.0-beta3').

The ajax filtering, ajax pagination which comes part of 'view ajax' is not working. The same view is working using the core theme 'Seven'.

The following JavaScript error is occurring while using pagination

ajax.js?v=8.1.0:1213 Uncaught TypeError: Cannot use 'in' operator to search for '.js-view-dom-id-f891bca9a3fa1028e173a98fc85fe129a07d3ec7ccb46915ffc193d8c7c77028' in undefined

Thanks

There have been commits since beta3 (specially #2638816: Ajax not working for views pager). Try the latest dev.

Also, please do not re-open old issues.