I've exposed a filter for node title and it seems the auto submit doesn't work. It is working on selection lists.

Is this by design or am i missing something? I'd like the view to update result for the 'onchange' event in the text field?


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


infojunkie’s picture

Text fields send an "onchange" event only when you tab out of them or focus on another element, but *not* as you type inside the field. Can you confirm that this is what you're seeing?

hixster’s picture

Can you confirm that this is what you're seeing?

Hi Info junkie, yes it's working as you describe, so that's how it's supposed to be. I was hoping I could get some kind of live search going.

Thanks for the quick response.

infojunkie’s picture

Status: Active » Closed (won't fix)

Live search in that context would consume a lot of resources: each keypress would cause the view to be re-evaluated and re-rendered, whereas you're probably typing in a sub-string that you want to match against existing titles.

I can suggest two alternate approaches:
* An auto-complete title filter - not sure if that exists today
* Use Views Filters Selective on the title filter, which will convert the title input field to a drop-down containing all titles in the current view results. Views Filters Selective is available in this module package (Views Hacks).

In the mean time, I'm marking this as closed. Feel free to update the thread with your solution.

mstrelan’s picture

It would be good if we could selective enable this ... and perhaps after a 1 second time out or something. Every keystroke can reset the timeout. I have a view that simply returns titles and is not very resource intensive. If I use the auto submit function the submit button is removed and users don't know they need to lose focus of the input field.

amal850720’s picture


infojunkie’s picture

Category: support » feature
Status: Closed (won't fix) » Active

OK, I revert from my "won't fix" stance. Leaving this as a feature request for whomever might want to step up and submit a patch.

amal850720’s picture

i'm not that much of a php guru, but i modified lines #19 and #22 in views_filters_autosubmit.js from "change" to "keyup". it worked well, but the whole page loads instead of the results region. how do i instruct the function to only update the results region?

infojunkie’s picture

If you turn on Ajax in your view, only the results region should change.

Beyond this core functionality, we need to add settings to control where the keyup functionality gets activated: per view and/or per filter. There's a lot of code to be written there.

eL’s picture

For autocomplete field it doesnt work too.

eme’s picture

Well it does work but issue is that if you change that you cannot run the other select (so you cannot mix textfield with select).

For better performance, it would be great to be able to launch not on keyup but after a little delay to let user type in some letters and run the view less times.

clintthayer’s picture

Confirmed the change in #7 "works" but agree with #10 that a delay would allow the user more time to key in more text. I also notice focus is lost when the re-fresh happens. This could be a killer feature...

+1 for trying to add this in.

timd.mackey’s picture

I really like this idea, and I think implementing it with a delay would be a good way to go. The current implementation is a little counter-intuitive in my mind, most users don't expect to have to "tab" away from the input field to submit it.

+1 for adding this feature.

sk33lz’s picture

Hey folks,

I was looking to add this functionality to a fairly large filter set and stumbled upon this issue. I did a bit of searching and found this new module, http://drupal.org/project/views_autocomplete_filters. It is pretty slick as it allows you to autocomplete for a text field on each filter and when you hit enter to submit the autocomplete, it views hacks auto submits just fine :) Users probably won't even notice the difference. Seems to at least saved a step for me to run a query and is pretty intuitive for users. Not sure if that fixes everyone's issue on this, but it works for me.



timd.mackey’s picture

Well here goes, this is the first code submission that I've ever made!

Running with the ideas in #7 and #11, I made a couple modifications to views_filters_autosubmit.js so that the autosubmit is now triggered after each keystroke, with a defined delay. I set the delay to 1 second after each keystroke, and any additional keystrokes reset the timer. I left the code for "select" boxes as is, since they already autosubmit as soon as an option is selected (which seems to me to be the correct behaviour).

As was mentioned in #11, field focus gets lost when the form is submitted. This problem occurs even without autosubmit being enabled. The solution I came up with was to store a browser cookie with the currently focused field, and to reset the focus after submit by using that browser cookie. The cookie gets updated each time the user selects a field, and it is erased when the user clicks away from the fields.

I've only tested this so far with Safari and Firefox on Mac, so I don't know if it works with all browsers (although I hope it does!) Also, the code is a bit messy, and it might not follow proper drupal coding standards since I'm not very familiar with them.

Any comments or improvements are welcome.

EDIT: I just noticed that the dev version of this file has some changes from the beta1 file I was working from. If more work is done on this, should it be based on the dev version?

eme’s picture

Yes indeed, you should work only on the dev version as it is the future release.

infojunkie’s picture

Version: 6.x-1.0-beta1 » 6.x-1.x-dev
Status: Active » Fixed

Thanks to timd.mackey for the patch! I committed the autosubmit with timeout part, not the cookie part - I didn't feel comfortable with creating a new cookie just for this. Please try it in the latest dev (12 hours from now).

timd.mackey’s picture

Hey infojunkie, thanks for accepting the timeout part.

As for retaining field focus, I see it as being essential to the purpose of this submodule, so I think we should continue to discuss it. In my mind, the purpose of autosubmitting the filter is basically to have a semi-live filter on the view, and if the user has to reselect the the form every time he makes a change, it kind of removes the benefit of autosubmitting and complicates an interaction that AJAX is supposed to make simpler. (I should clarify that all of what I'm saying applies primarily to textfield inputs, since check-boxes, radio buttons, and select-dropdowns and one-click choices and require the use of the mouse anyways.)

It appears what is causing this problem in the first place is that when the view gets updated via AJAX, Views is reloading the entire contents of view.tpl.php, which includes the exposed filter form. The field focus is lost because the filter form is getting replaced by a new copy of itself after you submit it. The best solution to this would obviously be if the form field wasn't getting replaced each AJAX call, but it seems to me that would require a rewrite of the way that Views handles its theme files, which I think is rather out of the question.

As for an actual solution to this, I think any solution is going to require javascript. Javascript is the only way (currently) that you can tell the browser to focus on a particular field when a form is loaded to the page. So the question remains of how to keep track of what field is currently in focus. I can see two ways of doing it:

  1. Use a Session Cookie. I've already demonstrated this in the javascript file I posted in #14, and it works very well on my site. I'm using it on my User Management Page and my Node Management Page (both of which are VBO views) in the site administration, and it has made the whole process of finding user and nodes way faster.
  2. Use a hidden field. This seems a little more complicated, but I think it might be a better solution. What I'm thinking is that we use hook_form_FORMID_alter() on the filter form to add a hidden field; This field would start out blank, and using javascript, would be dynamically updated with the value of the currently focused field. After the form is autosubmitted, we can pull the value of the hidden field and use it to restore focus to the right field.

Any thoughts? I think I'm going to go now and make an attempt to implement the second option.

timd.mackey’s picture

This actually ended up being a lot simpler than I had thought when I wrote my last post! I whipped up a patch which implements field re-focusing using a hidden field on the exposed filter form, which I think you will agree is a much cleaner solution than using cookies. However, I did run into one issue which I have yet to resolve (this issue does not occur with the cookie method): After autosubmitting, the id of the focused form field gets embedded into the pager links, so if you click on another page in your pager, focus is applied again to the previously focused field. I have yet to think of a solution to this, so any ideas are appreciated.

Note: I removed lines 19-21 from the development .js file as they were redundant and were interfering with the new timed-delay autosubmit on the textfields.

timd.mackey’s picture

I found a solution to the problem I mentioned with the pager embedding the focused field, but now that I've found I'm not sure if it is really a problem or not. Anyways, here is the change:

In views_filters_autosubmit.module, after applying the patch, change:

$form['views_exposed_form_focused_field']['#type'] = 'hidden';


$form['views_exposed_form_focused_field']['#type'] = 'hidden';
if($_GET['page'] > 0) {
  $form['views_exposed_form_focused_field']['#value'] = NULL;

Since submitting a filter will always load "page 0" (the first page), this makes sure that the hidden field value is cleared upon clicking to another page.

infojunkie’s picture

Great stuff. I tested your patch + fix and it seems to work just fine. Committed them to the latest dev, with a few minor edits.

infojunkie’s picture

Status: Fixed » Active

The code

if($_GET['page'] > 0) {
  $form['views_exposed_form_focused_field']['#value'] = NULL;

doesn't seem to be removing the field from the next pages' URL. Isn't this what it's supposed to do?

eme’s picture

Tested on Chrome with great success. To my mind, it would be great to be able to configure the delay via ui (autoSubmitDelay).

Would allow to choose between performance and efficiency. Just put the thing at 100 on a lightweight drupal install, and it is just as fast as Google (not the same with 1000).

infojunkie’s picture

@eme, I agree about admin settings. I just need to figure out how to place them - right now they are placed outside the view, which is annoying.

timd.mackey’s picture

@infojunkie, the code you cited in #21 doesn't actually remove the field from the URL (I'm not sure how to modify the pager), all it does is override the value of the hidden field when the form is written. That way when you go to a page other than "page 0", the JavaScript code checks the hidden field to find out which field should be focused, and comes up with an empty value.

Btw, I've also been writing a patch which allows you to specify which view display you want to use autosubmit on, instea of showing it on every display of a single view. I'll create another issue for that once I'm done.

infojunkie’s picture

@timd.mackey, even though the form alter function sets the value to NULL, I still see the original field name on the URL in subsequent pages. Can you confirm this?

timd.mackey’s picture

@infojunkie, that is correct, the field name is still present (likewise the hidden field is also still there), but the value is empty. We want to the field to remain on all pages so that it can be written to again if the user alters the filter and submits the form again.

infojunkie’s picture

Sorry, I meant to say: the field name *and* its value are still present on the URL.

timd.mackey’s picture

Oh, you're right, it is still there. Hmmm... Well, it still seems to fix the problem, it must be magic ;-). After filtering, when you click to another page in the pager, does your browser re-focus to the form field? I'm not sure why the field still appears to have a value, but it does seem that this prevents the browser from jumping focus back to the form field.

Vacilando’s picture


ressa’s picture

I just tried the latest dev version from 2011-Sep-05, and if I understand it correctly, the page should scroll down to where the exposed filters with check-boxes are situated, right?

But the page doesn't scroll down when you check some boxes off, but refreshes the entire page and jumps to the top.

How about adding an option to the auto-submit module of adding something like "#autosubmit-focus" at the end of the URL, and then people can insert the anchor HTML in the view themselves?

drupive’s picture

thanks a lot for all the work.
I have a few dropdownmenu's and one auto-complete in one exposed form.

1 second delay was not sufficient for my situation, it was to short to select a term that shows up, so I ended with incomplete words creating errors "Unable to find term: .."
so I changed it to 3 seconds first. But then when someone to enters a term that's not there, even 3 seconds was not enough.

I ended up disabling auto-complete for inputs and left the submit button visible, that was in my case more user-friendly

So It might be good to have hiding the submit button and auto-complete inputs optional.