Ajax error 500 on exposed filter / No errors with account 1

I am also encountring this issue on my live server, but on my local install there are no errors, Its really strange.

I have the same problem. I have setup the autocomplete on the Title field on the Content admin views. My setup is a little bit different as it is NOT a coumpounded field but just basic Title. It works with admin and not with other roles. I have looked up in the rights of that role but found no right I could give it to make it work.

As i can't reproduce it i'll need more details how this could be "achieved".
May i have some Views exports and some permissions.
Thank you all.

I am getting this error when selecting BEF for my view (after a delay):

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: http://mysite.com/admin/structure/views/ajax/display/user_directory/page/exposed_form_options
StatusText: Internal Server Error
ResponseText: 

Not getting this with basic or input required.

Also seeing this issue when selecting BEF settings in the Exposed form in Views. I receive the AJAX 500 error after clicking Apply for my changes. I cannot update More Options or my Display filter type because of this issue.

I'm using BEF 7.x-3.0-beta4, Views 7.x-3.8, and Core 7.34

Same issue but only for anonymous users, for authenticated users it deosn't happen.

I am experiencing what I think is the same (or a similar) issue. My case is as with the OP - no problems when logged in as UID 1, but any other authenticated user using the autocomplete filter sees a 500 error back from the AJAX request.

I see the memory exhaust problem as well, and if I have XDebug turned on I get a warning about function nesting depth.

My investigations have led me to conclude that there is an infinite loop triggered by my use case - I can't work out what the correct behaviour is intended to be but the behaviour as I see it is that, when _views_autocomplete_filters_access_callback calls the access method on my view, this then triggers the following cascade:

views_plugin_display->access()
views_plugin_access_menu->access()
menu_get_item()
_menu_translate()
_menu_check_access()
_views_autocomplete_filters_access_callback()

ad nauseam.

I can provide version and line numbers for the various modules involved but I'm basically running the current (as of today) version of all the modules involved as well as D7 core.

My view is a 'system' view, which I think may be relevant as it's not possible to specify a custom access condition of any kind for these as far as I can tell, at least not in Views UI.

If the maintainer can elaborate on how things are meant to work I'd be happy to attempt a patch but, as I say, I can't work it out from first principles so am a bit stumped right now.

An update on my experience with this:

I've managed to work around my particular case by using a hook_menu_alter() implementation to change the access callback for autocomplete_filter/%/%/%/%. In my case, I simply amended it to use user_access and passed in the name of a permission that coincides with the user profile for the View I'm using the exposed filter on. This works here because I'm only using Views Autocomplete Filters in one place on this site but obviously a more nuanced, custom callback could be written for more complex cases.

/**
 * Implements hook_menu_alter().
 * 
 * @param array $items
 */
function my_module_menu_alter(&$items) {    
    $items['autocomplete_filter/%/%/%/%']['access callback'] = 'user_access';
    $items['autocomplete_filter/%/%/%/%']['access arguments'] = array('some permission or other');
}

Sorry - I accidentally deleted the issue summary! Re-instating ...