Author Topic: Glitch with 'sticky' autocomplete on forms? Or by design? (Read 1445 times)

alanms · December 16, 2010, 10:19:15 am

I've been investigating a glitch which has been making adding contacts frustrating and getting many complaints from users. You can try it on the 3.3 demo, but you have to type super-fast to outpace the tiny demo database.

On autocomplete fields in forms (but not on the autocomplete-fuelled quick search in the top left), when you type an entry that doesn't exist, after the AJAX function tries and fails to find the contact with each character you type, the HTML element for the autocomplete results shows the string you typed and wrenches focus away from whatever form field you're working with, back to the autocomplete field.

So, say you're adding a contact with a new, long organisation name - say, 'Bill & Melinda Gates Foundation'. You type it, and move on to a new field. Autocomplete searches 'B', 'Bi', 'Bil', 'Bill', 'Bill ', and so on, and builds up a backlog of AJAX requests. The problem is, instead of each failed search returning nothing and therefore doing nothing in the user's browser (like the quicksearch and all the examples on http://view.jquery.com/trunk/plugins/autocomplete/demo/ ), failed form autocomplete actions return the original string, returning focus to the field and showing the input string formatted as if it was a result.

So, when a user has typed the org name and is now trying to enter an email address or phone number, Autocomplete interrupts them, wrenches the cursor back to focus on the autocomplete field, and shows them a redundant autocomplete results list containing 'Bill & Meli', then again when it completes searching on 'Bill & Melin', and again for 'Bill & Melind', and so on.

After snooping I found this was nothing to do with autocomplete config or client-side jquery at all, and seems to be purely a result of the server-side search process returning the original string instead of nothing when nothing is found.

I can't see any benefit to doing this, but, since both this and the quick search autocomplete (which has no such problems) seem to use the same AJAX.php routed from a REST URL, someone must have coded some kind of switch to force this to return the input string for some requests, and nothing for others.

Is there a reason for returning the input string? Will something subtle break if this is changed? Or is this accidental collateral from something else that can now be safely removed?

Dave Greenberg · December 16, 2010, 05:05:24 pm

Alan - Can you give an example of the forms that exhibit this behavior? (I think you're talking about the "Select Contact" field in forms like "Add Contribution" in the mode where you haven't started from the context of an existing contact record - http://drupal.demo.civicrm.org/civicrm/contribute/add&reset=1&action=add&context=standalone).

I did run a test in the 3.3. demo using Firebug console, and I think I'm getting an empty return for non-match inputs. I'm testing this by opening the request in another tab. Example URL:

http://drupal.demo.civicrm.org/civicrm/ajax/rest?className=CRM_Contact_Page_AJAX&fnName=getContactList&json=1&context=newcontact&s=ax&limit=10&timestamp=1292547720433

That said, I don't understand how this stuff works completely. You might need to grab Kurund on IRC to discuss further.

alanms · December 17, 2010, 02:22:49 am

Hi Dave,

Thanks for the reply - it was specifically the 'Current Employer' field on the 'Add contact' screen that was giving us headaches (http://drupal.demo.civicrm.org/civicrm/contact/add&reset=1&ct=Individual - mashing keys is the easiest way to replicate on the demo DB which only has a couple of organisations). There were a few other places I noticed this as well so I assumed it was everywhere, I'll just see if there's any obvious pattern...

...hm, strange, there's only two places I can find where it does this - most places seem to do the more normal no-return. They are, the 'current employer' field, and custom fields set up using 'Contact reference'. They use these REST parameters:
/civicrm/ajax/rest?className=CRM_Contact_Page_AJAX&fnName=getContactList&json=1&context=contact&org=1
/civicrm/ajax/rest?className=CRM_Contact_Page_AJAX&fnName=getContactList&json=1&reset=1&context=customfield&id=8

It looks like the culprit must be something targeting 'context=contact' and 'context=customfield' as these parameters are otherwise near identical to the relationships url, which returns nothing when there's no match:

/civicrm/ajax/rest?className=CRM_Contact_Page_AJAX&fnName=getContactList&json=1&context=relationship&rel=' + relType

'context=contact' I could imagine having an additional purpose that makes some use of the returned string, but I can't see any use for it in 'context=customfield', so I'm starting to suspect that this is just a bug.

Kurund Jalmi · December 17, 2010, 10:24:40 am

Quote

On autocomplete fields in forms (but not on the autocomplete-fuelled quick search in the top left), when you type an entry that doesn't exist, after the AJAX function tries and fails to find the contact with each character you type, the HTML element for the autocomplete results shows the string you typed and wrenches focus away from whatever form field you're working with, back to the autocomplete field.

For current employer we show this behavior because if you select non-existing values it allows you to create new organization along with relationship.

We are also using a old version of autocomplete plugin.

Kurund

alanms · December 19, 2010, 05:28:03 pm

Great, thanks for the clear answer. So if that's all it's for, I can cut out the AJAX return string without any worries about anything breaking, as it seems the new organisation name is generated where applicable from the input field value rather than anything depending on autocomplete.

lcdweb · January 05, 2011, 02:40:49 pm

alanms: we adjusted minchars on some of these to a value of 3, which helped performance on large dbs -- it doesn't attempt a search until the user types 3 characters.

xavier · January 06, 2011, 02:18:30 am

Hi,

They are two (related) issues that makes the code slow on the server (and cause the problem to be visible)

1) if you search on both email and name, the search is very slow (union between two unrelated tables). takes several 100ms as soon as the database has k contacts
2) the search is on %string%, so it slower, and if you have "doe, bill" and a few dozen bills before the bill and melissa org, you will have to type a lot before getting the right subset of contacts

X+

alanms · January 06, 2011, 08:54:26 am

Thanks to xavier & lcdweb for the tips on performance. I've also had the main quick search set to only start searching after at least 3 characters and it helps reduce the seperate problem of search results going haywire trying to keep up with the input.

For this specific problem, of data entry being made frustrating by the cursor being dragged back into the 'Current Employer' cell after each and every lookup finally finishes, I've found a fairly simple fix. It makes the field behave like other autocomplete fields, not showing empty result sets and leaving the cursor alone when there's no results to show. It also covers the purpose that Kurund alluded to - using a different, more discrete method to create a new organisation and relationship when replacing an existing employer with one not currently in the database.

So, with this change, everything works as before: new organisations are created where needed, the notice is shown to state that this will happen when it's going to happen and is hidden when it isn't, etc.

The only difference is removing the potentially frustrating glitch from the interface. There's no longer a black box slowly trying to catch up with what you type when there's no results to show, and the cursor doesn't get dragged irritatingly back into the input box when you've finished typing and have moved on to a different task.

Here's the code, 3 simple changes to 3 files.

Change 1: To stop the AJAX search returning the input as if it was a search result:

In file CRM/Contact/Page/AJAX.php near line 170, delete or comment out this block of code:

Code: [Select]

        //return organization name if doesn't exist in db
        if ( !$contactList ) {
            if ( CRM_Utils_Array::value( 'org', $_GET) ) {
                echo CRM_Utils_Array::value( 's', $_GET );
            } else if ( CRM_Utils_Array::value( 'context', $_GET ) == 'customfield' ) {
                echo "$name|$name\n";
            }

Change 2: To make a new organisation be created and the Current Employer field change if an existing employer record is replaced with an empty one (and also, to make consistent the display of the '(new contact record)' text):

In file templates/CRM/Contact/Form/Edit/Individual.tpl near line 140, add the following to the options for cj('#current_employer').autocomplete

Code: [Select]

    
	      matchContains: true,
	      parse: function(data) {
	        if (data) { 
            cj('div#employer_address').html('').hide();    
	        } else {
	        // Brief pause to minimise layout jumping up and down during typing
            setTimeout( function() {
              cj('div#employer_address').html(newContactText).show();
              cj('input#current_employer_id').val('');
              },400);
	        }
        }

Change 3: So that Custom Field auto-lookup contact reference fields still give the 'Please enter a valid contact' error if you replace a valid contact with one that doesn't exist

In file templates/CRM/Custom/Form/AutoComplete.tpl near line 38, add the following to the options for customObj.autocomplete

Code: [Select]

              matchContains: true,
	      parse: function(data) {
	        if (!data) { 
              customIdObj.val('');
	        }
        }

CiviCRM Community Forums (archive)

News:

Author Topic: Glitch with 'sticky' autocomplete on forms? Or by design? (Read 1445 times)

alanms

Glitch with 'sticky' autocomplete on forms? Or by design?

Dave Greenberg

Re: Glitch with 'sticky' autocomplete on forms? Or by design?

alanms

Re: Glitch with 'sticky' autocomplete on forms? Or by design?

Kurund Jalmi

Re: Glitch with 'sticky' autocomplete on forms? Or by design?

alanms

Re: Glitch with 'sticky' autocomplete on forms? Or by design?

lcdweb

Re: Glitch with 'sticky' autocomplete on forms? Or by design?

xavier

Re: Glitch with 'sticky' autocomplete on forms? Or by design?

alanms

Re: Glitch with 'sticky' autocomplete on forms? Or by design?