Autocomplete.js errors with Mozilla based browsers, due to a namespace conflicts between search terms and object properties

lol. Turn off Firebug!

This is a namespace clash with Mozilla browsers within the core Drupal autocomplete.js

Browsers:
FireFox 3.5
SeaMonkey 1.1.17
Galeon 2.04

So far the following name cause logical error during the auto-complete process:

no autocomplete AJAX, no drop-down
constructor

no autocomplete AJAX and [object Object] is shown in the dropdown and prototype is returned when selected

# Some methods inherited from Function.prototype
toSource
toString
valueOf

# All methods / properties inherited from Object.prototype
propertyIsEnumerable
hasOwnProperty
watch
unwatch
__defineGetter__
etc

Some keywords appear to pass, like some methods / properties inherited from Function.prototype: apply, call, name, caller, length, ...

The easiest workaround is to add a prefix to the search cache object to preserve the namespace, but what implications that this has to contributed modules is unknown.

   // See if this key has been searched for before
-  if (this.cache[searchString]) {
-    return this.owner.found(this.cache[searchString]);
+  if (this.cache['drupal_' + searchString]) {
+    return this.owner.found(this.cache['drupal_' + searchString]);
   }

The following patch uses this approach.

I'll test against a Drupal 7 install in a few hours. Both use the var cache = {} so I would assume that this is an issue with D7 HEAD to.

Alan

Added a screenshot of the issue using an autocomplete on the DO issue search page, but all keyword checks were done using the issue settings Project autocomplete on FF3.5

This does not appear to happen on IE. For once, they appear to have got it right!

Confirming that this is an issue with Drupal 7 HEAD. New patch is against this.

Ha! What a funny problem! I was able to sort of reproduce this in D7. Instead of getting [object Object] though, I get 'prototype' when I enter 'watch' and click on the barely visible drop-down.

Another bug I ran into is if you type in something that's not found, and click the down arrow, then tab out of the field, you get 'undefined'. But this happens with or without this patch.

I'm curious, is there a way to name-space these that's more specific to the autocomplete widget (machine-readable ID or similar) than a generic 'drupal_' placeholder? In general, we try and avoid hard-coding 'drupal' assumptions in any user-facing code. I'm also not sure what effect this has if there is more than one autocomplete field on a form (though probably none, since only one of these can be typed in at once).

The object is an internal property of the AutoComplete DataBase object that is created for each URI (if I'm reading the JScript correctly) so it shouldn't be used anywhere else.

E.g. acdb[uri] = new Drupal.ACDB(uri);

Happy to change but I do not think that it needs any special treatment for the above reason. 'acdb_' + searchString or 'acdb_cache_' + searchString ?

I mimicked the arrow bug, but I haven't the time to look at it. This is definitely another issue.

The attached patch uses 'acdb_' + searchString.

Oh. So that's what ACDB stands for. Thanks! :)

And sorry, I didn't ask my question clearly enough. What I'm basically wondering is whether there's something like a this.parent.getId() (excuse my horrible pseudocode) which we could use for this prefix? So in the case of the autocomplete username field on the node add/edit form, it'd be "name_XXX" and for taxonomy it'd be... oh dear lord... taxonomy_tags[zxx][value]_XXXX :P ok so maybe not the ID but... something about the autocomplete instance that would uniquely identify it.

Basically, I'm just a little concerned about what happens if I have a user "kitten" and a taxonomy term "kitten"; how does this affect the cache if they're both using the same prefix for the value?

Each have their own autocomplete ACDB object, as these are based on the URI (See where the behaviour attaches ~lines 8), if I'm reading the JScript correctly.

E.g. Using the term & user autocomplete as examples, (with made up URLs), the caches will be different.

acdb['taxonomy/autocomplete/3'].cache

acdb['user/autocomplete'].cache

Each with their own cache object, so there should be no overlap, and if there was (eg: two user autocompletes), the results would be the same anyway as they would be sharing the same acdb object & URI. I was worried about adding a parsed id based prefix which wasn't needed in case it created other bugs... Call me cautious

subscribing

#10: autocomplete-cache-namespace.patch queued for re-testing.

Dumb patch bots - only some work with Windows line endings....

Re-rolled using UNIX line endings, nothing else has changed.

#18: 590148-18-autocomplete-cache-namespace.patch queued for re-testing.

Wow, lost track of this one. Let's get this fixed.

Oh so sorry to do this. Has to go into D8 first.

This would fix it: #675446: Use jQuery UI Autocomplete.

A much cleaner solution is here #784670: autocomplete.js can iterate over functions in Array objects. Worth voting for even if JQuery UI Autocomplete makes it into D8.