when clicking on one of the suggestions execute search

I'm just using Drupal's "native" autocomplete functionality using the Form API, so I guess it's a matter of finding out how to make *any* #type = "autocomplete" field in Form API autosubmit upon clicking.

That, or building a new autocomplete widget using JS that does what you need. Perhaps I'll look into it if it becomes a usability problem... leaving open for now.

That's right -- this is actually a feature of Drupal's autocomplete. Because autocomplete can be used in forms with several fields, it's not desirable to submit the whole form after changing one field.

However, if you only use autocomplete for one single-field search form, you can override one JavaScript function to achieve submitting:
edit: there was an error in the original Javascript code. This version has been tested and works.

  if (!!Drupal.jsAC) { // this condition tests if autocomplete has been enabled 
    Drupal.jsAC.prototype.hidePopup = function (keycode) {
      // Select item if the right key or mousebutton was pressed
      if (this.selected && ((keycode && keycode != 46 && keycode != 8 && keycode != 27) || !keycode)) {
        this.input.value = this.selected.autocompleteValue;
        $('#search-theme-form').unbind('submit'); // replace '#search-theme-form' with your search form id
        $('#search-theme-form').submit();
      }
      // Hide popup
      var popup = this.popup;
      if (popup) {
        this.popup = null;
        $(popup).fadeOut('fast', function() { $(popup).remove(); });
      }
      this.selected = false;
    };
  }

(The original function can be found at misc/autocomplete.js, line 155.) Maybe you could also make this happen only on forms with some specific id/class.) This code will submit the search form even if autocomplete was used for other forms on the page.

I can't see this becoming a feature of this module. Thanks tituomin for the helpful example for those who need to modify things to their needs.

(sorry for the duplicate @ http://drupal.org/node/830064 )

I'm using the code from #2, works like a charm. Thanks tituomin!

This is a great script and works well when the user clicks an autocomplete suggestion. However, if the user wants to type keywords and hit enter without selecting an autocomplete suggestion, they have to press enter twice. How would I modify the script to hit enter just once to activate the search?

^^ I second what ianchan said.

Me too... at the moment it just appears that the search is broken

This may be a minor issue technically, but it's a major usability issue and just makes your site seem broken. While I don't have a good solution to offer, I don't think it should be dismissed as something that can be worked around with some custom Javascript.

EDIT: I see that this is all core autocomplete stuff and it probably won't be changed for Drupal 6.

Here's the modified version of #2 that I had to use. I wanted the search to execute on enter even if there was no autocomplete item selected.

Drupal.jsAC.prototype.hidePopup = function (keycode) {
  // Select item if the right key or mousebutton was pressed
  if (this.selected && ((keycode && keycode != 46 && keycode != 8 && keycode != 27) || !keycode)) {
    this.input.value = this.selected.autocompleteValue;
    $('#search-form, ').unbind('submit'); // replace '#search-form' with your search form id
    $('#search-form').submit();
  }
  else if (keycode && keycode == 13) {
    $('#search-form').unbind('submit'); // replace '#search-form' with your search form id
    $('#search-form').submit();
  }
  
  // Hide popup
  var popup = this.popup;
  if (popup) {
    this.popup = null;
    $(popup).fadeOut('fast', function() { $(popup).remove(); });
  }
  this.selected = false;
};

I also commented out alert(Drupal.ahahError(xmlhttp, db.uri)); in autocomplete.js to avoid error popups since I never want users to get a popup just because the autocomplete didn't work.

I've been convinced to look into this; I might need to look for a suitable GPL'd JS autocomplete library that handles this (and also the problem mentioned in #897408: Don't require user to press Enter twice when no suggestion is chosen).

Basically, we're un-sucking the Drupal Forms API #autocomplete widget =)

The good news is that jQuery UI has an autocomplete widget:
http://jqueryui.com/demos/autocomplete

The bad news is the widget requires jQuery UI 1.8.x which is not currently supported by the Drupal module. In my experience jQuery UI 1.8 also has a number of API changes from 1.6/1.7 so the only easy way to get there from here is to start building a module dependency tree on jquery_update and jquery_ui, which may not be desirable.

The previous jQuery Autocomplete module, which does seem to work with jQuery 1.2.6 (as shipped with D6) is here:
http://bassistance.de/jquery-plugins/jquery-plugin-autocomplete
http://docs.jquery.com/Plugins/Autocomplete

Unfortunately that is also not developed and has a reference to using the jQuery UI version. It was, however, developed until fairly recently and there is a documented migration path to the jQuery UI version. Since Drupal 7 will include jQuery UI 1.8 this may be a good stopgap autocomplete feature for Drupal 6.

Migration looks pretty easy to the jQuery UI version that could be used with a Drupal 7 module:
http://www.learningjquery.com/2010/06/autocomplete-migration-guide

Here's a patch to get things rolling.

It's still incomplete... this works in my case but I've lost the result counts in the process, and I haven't really tested it.

Oops, the base directory was wrong. Here's a patch to apply inside the apachesolr_autocomplete folder.

I have done zero troubleshooting, but at least in my case with Pressflow and the jquery_update module, I get the following in the firebug console. Just reporting it for now, don't have a lot of time to dig in tonight.

I tried using jQuery Update module 2.x (updating jQuery to 1.3.2) and found no problems (so far). More info would be welcome =)

This is the TODO list so far (feel free to add stuff):
* go back to using drupal_json() to return results to the autocomplete JS
* do away with the in-JS string matching/highlight algorithm, use the existing server-side code (the new jQuery UI autocomplete widget doesn't have this one's client-side string matching/highlight code)
* see some file in the jquery-autocomplete/lib/ folder are needed; for instance jquery.bgiframe.min.js for IE compatibility.
* testing on different browsers, different jQuery versions, with/w.out jQuery UI... (what else?)

New patch...

Tested it under jQuery 1.2.6 and 1.3.2 (jQuery Update module 2.x), under IE8, Firefox 4 beta 6, Chrome under Windows.
Seems to work fine.

Haven't tested it under Pressflow, any takers? =)

This is how it looks:

Cross-referencing Kevin's patch at #897408: Don't require user to press Enter twice when no suggestion is chosen which is a lot simpler. I feel that that is the way to go with this issue as well.

@janusman

The patch in #15 works great. That's *exactly* how search suggestions/autocomplete should work if you ask me. It also feels cleaner and faster than the core version.

Using jQuery 1.2.6 I tested in...

Windows:
- Safari 3.1.2
- Firefox 3.0.12
- Internet Explorer 7.0
- Internet Exporer 6.0

OSX:
- Firefox 3.6
- Safari 5.0.1
- Chrome 6.0

Amazingly, IE7 and IE6 actually worked. First though, I had to ditch the trailing comma in apachesolr_autocomplete.js just after the function for formatItem. Apparently IE doesn't like those ending commas.

@wmostrey

I tried that patch also, and while it fixes the issue it was posted for, it doesn't seem to affect the original issue here where a user is clicking on an item.

@milesw++: Thanks for the rather thorough testing!! Glad to hear it works on IE 6/7 (!!)
Thanks for detecting that extra comma too. =)

@wmostrey: My concern about that patch in #2 at #897408: Don't require user to press Enter twice when no suggestion is chosen would be that other autocomplete widgets on the page would also change behavior. (I think?)

For instance, if the user is on a node edit page, and it has a taxonomy tags form element(s) (and the Search block is also shown on the page).

So I don't want the module to override global behavior of the same form element *types* on the page, but rather specific elements on the page. I'll try testing it anyway (and YES it *is* simpler and if it works, then it'd be the way to go =))

Marking as needs work from the comma problem found by @milesw (and will test the patch suggested by @wmostrey)

@janusman

Are you thinking you'll use the deprecated plugin for 6.x and eventually the jQuery UI version for a 7.x release?

@milesw: Yes =)

New patch for review.

Works nicely for me, however the patch does fail on apachesolr_autocomplete.css. Same happened with the patch from #15, but I assumed I needed to patch against dev. I just tried with both 6.x-1.0 and dev and it failed with both.

Subscribing and one question: patch #22 is against dev version or stable (probably dev because issue is labeled with 6.x-1.x-dev version)?

Tnx.

Supposedly, DEV. =)
Will look into it to see if I botched something.

Yeeey, this is really awesome!!! ;)

My colleagues will be happy because of enhancements. :)

Tested it on Windows 7 in Google Chrome 6.x, Mozilla Firefox 3.6.9 and IE 8 - everything is working A-OK!

I only needed to add some code to (my Garland sub)theme css to remove annoying list background image:

div.ac_results ul li {
background-image: none;
}

JFTR: This feature also solved other problem.

UPDATE:

I forgot to mention one issue that come up while patching, I suppose it's not so important(?):

patch -p0 < apachesolr_autocomplete-573574-22.patch
patching file apachesolr_autocomplete.css
Hunk #1 FAILED at 16.
1 out of 1 hunk FAILED -- saving rejects to file apachesolr_autocomplete.css.rej
patching file apachesolr_autocomplete.js
patching file apachesolr_autocomplete.module
patching file jquery-autocomplete/.cvsignore
patching file jquery-autocomplete/changelog.txt
patching file jquery-autocomplete/jquery.autocomplete.css
patching file jquery-autocomplete/jquery.autocomplete.js
patching file jquery-autocomplete/todo

@mariomaric
That was the issue I had also, and that's probably why you had to modify your theme. The patch includes an update to the CSS that hides those background images.

Tested #22

is working for me... had the same issues with the css part of the patch beeing rejected but added that manualy...

Thanks everyone for the testing. Yes, there is something wrong with the patch, and will fix it soon.

I am thinking that, regardless of this appearing to work completely, I will put in an admin option to choose whether to use the custom JS widget or the default Drupal autocomplete widget. I think the default will be the custom one, though. =)

Will roll a new patch soon.

Thanks again!

This is a new patch. It makes the new widget the default and includes support for falling back to the Drupal core autocomplete widget (by going to admin/settings/apachesolr/settings, opening the "Advanced configuration" fieldset and clicking the desired radio button under Autocomplete widget to use:

This applies to the current DEV version. Feedback welcome =)

Hi!

Again problem (with CSS) while applying patch (@ /sites/all/modules/apachesolr_autocomplete):

patch -p0 < apachesolr_autocomplete-573574-30.patch
(Stripping trailing CRs from patch.)
patching file apachesolr_autocomplete.css
Hunk #1 FAILED at 16.
1 out of 1 hunk FAILED -- saving rejects to file apachesolr_autocomplete.css.rej
(Stripping trailing CRs from patch.)
patching file apachesolr_autocomplete.js
(Stripping trailing CRs from patch.)
patching file apachesolr_autocomplete.module
(Stripping trailing CRs from patch.)
patching file jquery-autocomplete/changelog.txt
(Stripping trailing CRs from patch.)
patching file jquery-autocomplete/jquery.autocomplete.css
(Stripping trailing CRs from patch.)
patching file jquery-autocomplete/jquery.autocomplete.js
(Stripping trailing CRs from patch.)
patching file jquery-autocomplete/todo

So you need to inject css code manually..

Other than issue above, everything (including new admin UI option) is working OK @ Win7:
* Google Chrome 6.x
* Mozilla Firefox 3.6.10
* IE 8

Sorry about that CSS file problem. I think it was due to the files in CVS having CRLF instead of unix line endings.

Committed the patch from #30 to DEV.
Thanks everybody!

DOS files ftl!

Hah, forgot to set as fixed =)

This is truly awesome, thanks to everyone that contributed to make this happen!

.

#2 is working for me..tituomin Thanks.