Autocomplete does not work for views exposed forms

In terminal I can see solr found results but on screen nothing happens.

I guess this is a front-end JS issue? if you inspect and compare the html on the searchpage/search block with the html of the exposed form in blocks it's kinda different.

I'll have a quick look cause I also need this to work on exposed form blocks.

edit: Haven't found the cause of this issue yet.. anyone else has suggestions on how to resolve this? Thank in advance!

Did you select your view in the search-api index?

-> admin/config/search/search_api -> edit -> autocomplete tab?

Yes, all my views exposed form in block are selected in the autocomplete tab and it doesn't work. On every page (from search_api_page module) it works perfectly.

I too have an exposed form block in the homepage and everything is working beautifully. i'm using the 1.0.

Pix, is this exposed form block made with views? Or are you just using the exposed form block for from you search page?

Everything works here except the exposed form blocks made with views, something goes wrong here with the auto complete functionality.

This might be a long shot but it worked on my project; did you try putting an id on the input element?

The same situation for me. Using a exposed form the autocomplete doesn't work.

Ops, I make a mistake (and could be yours too f0ns)

This module give a new permission in permissions list. When I check the roles to use the autocomplete and check the exposed block from a view, the things running well.

Thanks

I will look into this later today. Need to check if this resolves the issue

f0ns,
the exposed block is made with views and it is generated by my search page. It's a "real" block placed in a specific region on every page.
Be sure to enable and select a field to use for you autocomplete suggestions under

admin/config/search/search_api/index/product_display/autocomplete/YOURINDEX/edit

Sorry, I could not reproduce this. It might be a problem with block caching, though, if you have that enabled. I'm not sure, but it might lead to the necessary Javascript not incldued on the page. Please see the source code of your page and check whether it includes the …/search_api_autocomplete/search_api_autocomplete.js Javascript file.

Still have this issue. All works except exposed blocks that come from views.

As said:

Please see the source code of your page and check whether it includes the …/search_api_autocomplete/search_api_autocomplete.js Javascript file.

JS is included on the page. I see the throbber moving but nothing is shown. Back-end of Solr shows x amount of hits.

Nothing is cached atm on the website.

I'll debug it further to find the cause.

edit: Still haven't found the issue here, the javascript answer is always empty, solr back-end shows my page has hits

When I search for "Down" in my global search exposed block I get answer:

{"Download":"\u003Cdiv class=\u0022search-api-autocomplete-suggestion\u0022\u003E\u003Cspan class=\u0022autocomplete-user-input\u0022\u003EDown\u003C\/span\u003E\u003Cspan class=\u0022autocomplete-suggestion-suffix\u0022\u003Eload\u003C\/span\u003E\u003C\/div\u003E"}

When I search for "Down" on my views exposed blocks:

(empty)

I checked every remark in this post and everything is setup as told. Also tested with 1.0 and 1.0-dev, same results

Recently i am also facing the similar issue in Drupal 8.7.5. We are using Exposed form as a Block and included it into the page using layout builder. I could able to see the suggestions but after choosing some suggestion

Here i am sharing more details. We using a module https://www.drupal.org/project/views_block_filter_block to make Exposed filters as a Block. And we adding those blocks into different sections in layout builder.

<!-- Here is the sample markup which is throwing error -->
<div class="section">
<!-- Exposed form -->
<form>
<input value="Auto suggestion field" />
</form>
</div>

<div class="section">
<!-- View listing -->
<ul>
<li>View row 1</li>
<li>View row 2</li>
</ul>
</div>

In this file <strong>search_api_autocomplete/js/search_api_autocomplete.js</strong> After ajax callback the context is limited to view listing which doesn't have <strong>'.ui-autocomplete-input[data-search-api-autocomplete-search]')</strong> hence that once function is failing. 

$(context)
        .find('.ui-autocomplete-input[data-search-api-autocomplete-search]')
        .once('search-api-autocomplete')

If it works fine with other views, and exposed form blocks based on Page displays, then probably the views_block_filter_block module is at fault. Have you tried with other setups?
Furthermore, do you mean to say that the behaviors are not applied for some elements on the page? It’s clear that, if an AJAX callback returns just the view listing, then the autocomplete behavior won’t be applied to that. But the behavior should have been applied to the rest of the page, including the input field, before that. If not, that seems like a different problem altogether.
Can you confirm that Drupal.behaviors.searchApiAutocomplete() is called more than once in this case? If the input field is there on the page, along with the right attributes, then it should be found in at least one of these calls.

Also, in the future, it’s usually better to open a new issue instead of reviving a six-year-old one – especially if the old one didn’t seem to be going anywhere.

I am still facing the same issue @f0ns has. What I did:

1. I created a Views page with views exposed form in block
2. I edited the admin/config/search/search_api/index/product_display/autocomplete/MYINDEX/edit to use the previous views page
3. I placed the views block on the site
4. I can see the throbbler being busy, but throws a 500 with the following error log in watchdog:

Symfony\Component\Routing\Exception\RouteNotFoundException type: Route "search_api_page.hu.my_view_machine_name" does not exist. message Drupal\Core\Routing\RouteProvider->getRouteByName() function.

Looks like the problem was on my side, I share my experience in case someone has the same case.

TL;DR: It should've been working at the first place, but an alter hook made the request failing.

• Previously we used search_api_pages for the results instead of views.
• To have the desired results, we implemented a hook_search_api_autocomplete_suggestions_alter() which added a new suggestion
• This new suggestion had a route which does not exists anymore

Moral of the story is, always check your error messages, search for the anomalys in your custom code base or contributed modules you use system wide and also try the module on a clean Drupal install.

Now we have a working solution for:
- We have a block placed on the page which uses a views and the autocompletion uses that as well, and it works.

How we did it?

Prerequisites:
- search_api installed and configured
- search_api_autocomplete installed and the user you're testing with has the correct permissions
- You have a working index for the content you want to use in the autocomplete

1. Create a new views page
2. Check "Exposed form in block"
3. Add new filter: full text search and select some fields of the entity
4. Edit your index at admin/config/search/search-api/index/YOUR_INDEX/autocomplete (replace YOUR_INDEX with your index)
5. Enable the previously created views and save the form
6. Click edit on the enabled views (you'll be navigated to admin/config/search/search-api/index/YOUR_INDEX/autocomplete/YOUR_VIEWS/edit where YOUR_INDEX is your index and YOUR_VIEWS is the previously enabled views)
7. My configuration:
   • Enable the autocomplete
   • Display live results
   • For which Views displays should Autocomplete be active? -> everything, except selected
   • Displays -> select everything and keep the one unchecked you had before
   • Enable autosubmit -> yes
   • Hit save
8. Navigate to admin/structure/block
9. Place the previously created views block on the site (search for something like "exposed form") -> I made no changes on the default configuration
10. Save the form
11. Check the site where it should appear according to your configuration
12. If the form appears it should have a throbber icon as well at this point.
13. Try to write some text - if it starts spinning, it's okay but still can have a problem if you can not see any results
14. Open developer console and check the "Network" tab for more information - using the input field for the search will bring up new requests so you can check them individually, and also you can check the Recent log messages @ admin/reports/dblog for more information.

And this works for us, hope it help for others as well. Spread the love! <3 Thanks for this awesome module!

I have now a similar issue, I had to update the site's ancient modules where this worked perfectly, and when I did it break. We using here BEF (I don't know how much it relates to the issue). What I was able to find out until now, that inside the search_api_autocomplete_form_views_exposed_form_alter the type textfield was changed to search_api_autocomplete. This is good, but not enough as the processors remain the Textfield one, therefore the SearchApiAutocomplete::processSearchApiAutocomplete is never being called. As result, I don't have the functionality (library and working autocomplete) even, if the markup looks like an autocomplete field...
In the end I had to do something like this to fix the issue, but it's not correct and it's far from perfect:

/**
 * Implements hook_form_FORM_ID_alter() for "views_exposed_form".
 */
function HOOK_form_views_exposed_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  if (isset($form['search_api_fulltext'])) {
    array_unshift($form['search_api_fulltext']['#process'], [SearchApiAutocomplete::class, 'processSearchApiAutocomplete']);
  }
}

I don't understand what needs to swap the process array on the form element, but it's clear that changing just the element type is not enough.

@ golddragon007: This seems like the exact same issue as #3159000: Autocomplete broken on views with Better Exposed Filters. Please try with the latest dev release. (I guess I should create a new stable release soon, too.)

Marking as fixed here. This issue can have so many different causes that it’s pretty useless discussing such different problems in the same issue. For future issue reports, please try to find out a bit more about why this fails before creating a new issue (like the last few commenters here did).