#15082 closed bug (fixed)
jQuery Autocomplete Duplicate Remove event listener — at Version 7
| 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 (7)
comment:1 Changed 4 years ago by
comment:2 Changed 4 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 3 years ago by
| Owner: | set to Scott González |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
In ef2e9ba:
comment:4 Changed 3 years ago by
| Milestone: | none → 1.12.2 |
|---|
comment:6 Changed 3 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 3 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.
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.