#15082 closed bug (fixed)
jQuery Autocomplete Duplicate Remove event listener
| Reported by: | jGeek314 | Owned by: | Scott González |
|---|---|---|---|
| Priority: | minor | Milestone: | 1.12.2 |
| Component: | ui.autocomplete | Version: | 1.12.1 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description (last modified by )
While trying to determine what was slowing down my autocomplete text box, I noticed that every time the user types in the target text box the number of event listeners would go up. It looks like autocomplete (or the widget factory?) is adding duplicate "remove" events to the target. This can be reproduced by adding the following line to the default autocomplete example at https://jqueryui.com/autocomplete/ .
response: function (e, ui) {
console.log( jQuery._data( $("#tags")[0], "events" ) );
}
When looking at the results in chrome's tools I can see the number of event listeners go up every time the the user types in the target text box.
Object {remove: Array[3], keydown: Array[1], keypress: Array[1], input: Array[1]...
Object {remove: Array[5], keydown: Array[1], keypress: Array[1], input: Array[1]...
Object {remove: Array[7], keydown: Array[1], keypress: Array[1], input: Array[1]...
Object {remove: Array[9], keydown: Array[1], keypress: Array[1], input: Array[1]...
http://plnkr.co/edit/Jk2xg3ZjJ5jS5mgP1zHZ?p=preview is a demo of the remove events growing.
Change History (10)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
Thanks to jGeek314 for the workaround in 10050, it works great:
search: function(e,ui){
//fix bug in jQuery.ui somewhere where menu.bindings just grows and grows
autoComplete.data("ui-autocomplete").menu.bindings = $();
},
comment:3 Changed 6 years ago by
| Owner: | set to Scott González |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
In ef2e9ba:
comment:4 Changed 6 years ago by
| Milestone: | none → 1.12.2 |
|---|
comment:6 Changed 6 years ago by
I think that this bug should not be closed, because the actual problem still exists. Before I wrote my (duplicate) bug report yesterday (thx for a quick response), I checked all open bugs but not the closed ones, which I think is a proper process.
comment:7 Changed 6 years ago by
| Description: | modified (diff) |
|---|
The proper process could also include:
- Checking tickets that are closed with a future milestone (which would have found this ticket).
- Testing against master to see if the bug still exists (which would have shown that it doesn't).
Neither of these steps are necessary for a reporter to follow, but we are definitely following a proper process. It would not make sense to keep tickets open they are released; tickets are closed when they are fixed. This is how every project I've ever seen has worked.
comment:8 Changed 6 years ago by
You are right, I should have checked those tickets as well and test against master, my bad.
It might be nice to see all open tickets and those that are already fixed but are targeted for a future version in a one list, I think it would be handy for developer. But as I said, my bad.
I did a new test against master version (https://jsfiddle.net/vm152La3/9/), and it works much better but still seems to slowly slow down when using Chome. I added console.log (in a breakpoint) to line 1596 in query-3.2.1.js to print the size of the results array and it seems to grow by every time a popup is shown. In Safari it grows as well but does not cause notifiable slowness.
And thank you and all developers for your work.
comment:9 Changed 6 years ago by
jquery-ui-git seems to have been broken for a long time. You'll notice the header comment says "jQuery UI - v1.12.0-pre - 2016-02-09"
I have also encountered a significant slowdown of autocomplete after upgrading from 1.11 to 1.12. It gets worse the more you use it, eventually slowing to a crawl.
Here's a demo: https://jsfiddle.net/Lm7xqs37/1/
It's a copy of the default example but with more autocomplete options and with delay set to 0 to make it easier to see the slowdown.
To reproduce: enter and delete a letter (e.g. 's') a number of times and see how it gets slower and slower.
Chrome CPU profiler result:
Chrome heap profiler shows that every time autocomplete search happens the old results div and li elements become a detached dom tree that can't get garbage collected.