Script.aculo.us AutoComplete Problem in IE

Question

I am struggling with a problem with Script.aculo.us autocomplete control in IE (I tried it in IE6 and 7). Offers are not displayed for the first character that is entered in the text box after the page loads. After this initial failure, the control works as it should.

I checked that the offer data is returned from the server correctly; the problem seems to be related to the positioning of the proposal element, as other relatively positioned elements on the page move out of position at the moment you expect the proposals to appear.

Has anyone heard of such a problem or any suggestions for fixing it?

Edit: In response to Chris, I set the partialChars parameter to 1, and the control works in all other browsers I tried, these are the latest versions of Firefox, Safari, Opera and Chrome. I probably should have done this first. Thanks.

Answer 1

I really have the same problem. The problem occurs only in IE (also in 8.0 beta)

Both Firefox and Chrome, which I tried, do not have the problems that have ever been.

According to others, this is due to the DOCTYPE declaration in the HTML file. Check here: http://prototype.lighthouseapp.com/projects/8887/tickets/32-ajax-autocomplete-in-ie-with-doctype

The error also received a ticket on the ruby ​​development boards: http://dev.rubyonrails.org/ticket/11051

Both links have solutions to fix the problem.

I hope the bug will be fixed in the next version of the / scriptaculous prototype :)

Answer 2

Thanks so much for hacking. I used this myself, but modified it, so it is only called when Ajax.Autocompleter is used, doing the following.

function positionAuto(element, entry) { setTimeout( function() { Element.clonePosition('choices_div', 'text_element', { 'setWidth': false, 'setHeight': false, 'offsetTop': $('text_element').offsetHeight } ); }, 300); return entry; } new Ajax.Autocompleter('text_element', 'choices_div', [url to web service], { paramName: 'fulltext', minChars: 2, callback: positionAuto, // See above [etc...] 

Since the callback is called immediately before the actual request, the positioning of the DIV at this moment makes the most sense. And make sure that even if the window is resized or scrolled, the DIV is positioned correctly. What is crazy is that in order to make it work sequentially, I had to wrap it in "setTimeout ()". Not experimented with different sync settings so much, but if there is a lower timeout threshold that works, I would like to know.

Tested on IE 8 and 7 and works very well. And works with other real browsers. Hope this saves some headaches from coders when dealing with this.

Answer 3

Is your problem only in IE or in all browsers? Ignoring the first char is actually the default value for autorun. In controls.js there is a class called Autocompleter.Local, which has a partialChars field, which by default is 2. The documents for this field say:

// - partialChars - How many characters you need to enter before starting // a partial match (unlike minChars, which determines // how many characters are needed for any match | // in general). The default is 2.

Answer 4

After long problems with this problem in IE8 / IE9, I ended up using CSS hack. The method here is to force a relative position in a container with an absolute location. An additional container is needed in order to float the selection over other elements.

 div.acwrap { position: absolute; height: 40px; } div.autocomplete { position: relative !important; top: -5px !important; left: 0px !important; width:250px; margin:0; padding:0; } 

In my HTML code, I used classes as follows:

 <div class="acwrap"> <div id="autocomplete_choices" class="autocomplete"> </div> </div> 

The idea arose here: Scriptaculous / Prototype IE 8 Problem with autocompletion of the problem .

Answer 5

I still don’t know what exactly caused this problem, but I managed to come up with a hack to it. The idea is to perform processing, which usually fails the first time a character is written, when the page loads, in order to eliminate it:

 new Ajax.Autocompleter(textInputId, suggestionsHolderId, suggestionsUrl, params); //Hack Event.observe(window, 'load', function() { try { Position.clone($(textInputId), $(suggestionsHolderId), { setHeight: false, offsetTop: $(textInputId).offsetHeight}); } catch(e){} }); 

Answer 6

This is a known bug with a patch that works but is not yet included. You can read more about this here: https://prototype.lighthouseapp.com/projects/8886-prototype/tickets/618-getoffsetparent-returns-body-for-new-hidden-elements-in-ie8-final#ticket-618 -nine