Conflict with ajax.js

i get the same error message. at first glance it seems to be related to the views ajax-options. when i disable the ajax view, the error is gone.

The problem is that views doesn't look for <button> for triggering an ajax control.

#1551534: Submit buttons themed as <button> element fail to trigger ajax in Views exposed forms

So unfortunately, I think for this one you need to patch views.

+1, I can confirm that the ajax is broken on views exposed filter search.

For me, this is an issue related to twitter bootstrap, not views. The goal of twitter bootstrap is to make drupal works with HTML5/boostrap libraries, views included (as we can consider that it's pratically a core module).

What about a form_alter to let the views button as it is with view core ?

We could do a patch, I will look into this. I agree with your comment but at some point we need to draw a line, as we can't patch all contrib.

In the mean time, the patch outlined in #2 definitely works.

I feel it is really something views should look at fixing though. I would advise you to +1 the issue in #2. Views should be able to support both input and buttons by default and not restrict themes into only using one or the other.

I can confirm that the patch works and it's more logical to fix it directly in view. By waiting that, maybe we could let the exposed filters submit as to keep compatibility.

Is it that imperative that we have the theme use <button> instead of <input>? Initially, it was a nice idea to use more HTML5 friendly semantics, but it may be causing more problems than it's worth. And the Bootstrap library should be element-independent, so the styling should apply just as well to an <input> type button.

It's a good point you raise.

I personally think it's good to try make other modules aware that <input> may not be a given and <button> should also be supported...

It's probably something Drupal should abstract at a low level in core (in an ideal world). Anyway, I'm using this functionality, so will work on a patch for this today.

Longer term, maybe in 3.x we provide as optional...

Agreed about 3.x, or maybe for the future D8 branch only... as i think this is an issue that has been brought up for D8. But actually, I'd support rolling back these <button> instances for 2.x if we run to to more problems, and just wait until either 3.x or D8 to re-implement.

its a pity but practicality > progress i guess. Maybe D8 will bring us some more html5 support.

Confirming that the the Views patch at #1551534: Submit buttons themed as <button> element fail to trigger ajax in Views exposed forms fixes this issue. My $0.02 is that this is indeed a Views bug because the module assumes input elements and not buttons, and buttons are perfectly acceptable markup for this implementation. Since Twitter Bootstrap uses the button element in it's examples, I wouldn't want to see this theme revert back to input elements to fix another module's assumption.

so can we lable this as wont fix?

Hi Frank,

Perhaps we can just keep this active for now. It probably helps people find the solution. At least until we can document the solution (or until views fix the issue).

Add active_tags and autocomplete_deluxe to the non-supported modules ...

I am gonna revert this locally - or rather override the button -> input change in the theme - if possible.

Yup, easily possible, for those that do not want this solution nor the hardcoded white list:

/*
 * Implements theme_button().
 *
 * Make <button> render as <input> for all cases as many contrib modules currently
 * break: views, active_tags,  ...
 *
 * @todo Revisit this function for later usage when contrib is more HTML5 compliant.
 *
 */
function mytheme_button($variables) {
  $element = $variables['element'];
  $label = check_plain($element['#value']);
  element_set_attributes($element, array('id', 'name', 'value', 'type'));

  $element['#attributes']['class'][] = 'form-' . $element['#button_type'];
  if (!empty($element['#attributes']['disabled'])) {
    $element['#attributes']['class'][] = 'form-button-disabled';
  }

  // @todo: We always return input elements for now, because <button> breaks many contrib modules and the exception white list is not extendable.
  return '<input' . drupal_attributes($element['#attributes']) . ">\n"; // This line break adds inherent margin between multiple buttons
}

@ Fabianx,

When you patch it like that, I needed to remove the complete $whitelist from the form.inc
, It worked for me when I had problems with Views-Quicksand module.
It is quite simple to use the $whitelist, but I agree that this is not sustainable.
I haven't tested the whitelisted elements so far, so I go with the solution to just add my Views exposed button #id filters to the $whitelist, so Views-Quicksand works.

I'm using the solution posted in #18 but it doesnt work for form created using form api.
It seem the element doesnt contain class ajax-processed.
Any idea to solve this issue?

As stated in #2120849-3: Decrease Panels IPE CSS & JS specificity to allow "button" elements:

Bootstrap modifies theme_button() to actual use the modern HTML5 tag. This allows for consistent x-browser styling compatibility. We won't start adding these kinds of "exceptions" into Bootstrap. They should be changed at the source where the actual issue lies: Panels (http://drupalcode.org/project/panels.git/blob/refs/heads/7.x-3.x:/js/dis...)

These types of issues occur when modules specifically use input in their module's JS jQuery selectors. This kind of conflict should be filed with the module that is causing them. That being said, I don't think this is really an issue any longer and seems to be working in 7.x-3.x. If not, please file an issue with Views.

views 7.x-3.7
jQuery 1.8.2

Still getting the same offending statement in ajax.js. The element triggering the ajax is a select list, an exposed filter. I can get this to work without ajax, of course; it would just be nicer if it worked without a page refresh.