Search and Top Navigation
#8878 closed bug (wontfix)
Opened December 02, 2012 10:13PM UTC
Closed December 03, 2012 12:56PM UTC
Last modified August 15, 2015 02:17AM UTC
Autocomplete: change event not fired on menu selection
| Reported by: | lubosdz | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 1.10.0 |
| Component: | ui.autocomplete | Version: | 1.9.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Hi,
autocomplete does not bind change event consistently. Following example would not trigger the "change" event in Internet Explorer (tested version 9) and Chrome (tested version 23.0).
<html>
<head>
<link rel="stylesheet" href="http://code.jquery.com/ui/1.9.2/themes/base/jquery-ui.css" />
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.9.2/jquery-ui.min.js"></script>
</head>
<body>
<input type="text" id="tags">
<br>
<input type="text" id="anything">
<script type="text/javascript">
$(document).ready(function(){
var availableTags = [
"ActionScript",
"AppleScript",
"Asp",
"BASIC",
"C",
"C++",
"Clojure",
"COBOL",
"ColdFusion",
"Erlang",
"Fortran",
"Groovy",
"Haskell",
"Java",
"JavaScript",
"Lisp",
"Perl",
"PHP",
"Python",
"Ruby",
"Scala",
"Scheme"
];
$( "#tags" ).autocomplete({
source: availableTags
});
})
$( "#tags" ).on("change", function(){
var date = new Date;
alert("changed.."+date.getMilliseconds());
});
</script>
</body>
</html>
After selecting menu item, the "change" event would not fire in IE(9) nor in Chrome.
It would fire change event in Firefox (tested 16.0.2) and Opera (tested 11.50).
After trying to fix issue by adding the option "select" like so:
select: function(event, ui){
$(this).trigger("change");
}
the "change" event was triggered two times in Firefox and Opera (causing 2 consecutive ajax requests), and only once in Chrome and IE9.
I discovered this bug after upgrading from previous version JUI (guess it was some 1.7.x) version.
Thank you.
Lubos
Attachments (0)
Change History (8)
Changed December 03, 2012 03:12AM UTC by comment:1
| status: | new → open |
|---|---|
| summary: | Change event not triggered in IE, Chrome → Autocomplete: change event not fired on menu selection |
Changed December 03, 2012 12:56PM UTC by comment:2
| resolution: | → wontfix |
|---|---|
| status: | open → closed |
We don't guarantee that the native change event is useful for enhanced widgets. Change events do not occur when the value is set programmatically, so it's always possible that the native change event isn't fired for any given input-based widget.
Changed December 03, 2012 12:57PM UTC by comment:3
Changed December 03, 2012 01:21PM UTC by comment:4
| _comment0: | @scott.gonzalez \ \ I think you misunderstood the nature of this bug - it has nothing to do with triggering the "change" event programmatically. The problem is, that the behaviour of autocomplete is completely different in Firefox, Opera and different in Chrome, IE even without trigger change event programmatically. \ \ Unfortunatelly, it is basically impossible to fix it - unless everybody writes complex JS tests what browser is being used and then dynamically attaches events. I have spend 2 days trying various ways around - no success:-( \ \ Thanx. \ Lubos \ → 1354540969315654 |
|---|---|
| _comment1: | @scott.gonzalez \ \ I think you misunderstood the nature of this bug - it has nothing to do with triggering the "change" event programmatically. The problem is, that the behaviour of autocomplete is completely different in Firefox, Opera and different in Chrome, IE even without trigger change event programmatically. \ \ Unfortunatelly, it is basically impossible to fix it - unless everybody writes complex JS tests what browser is being used and then dynamically attaches events. I have spend 2 days trying various ways around - no success:-( \ \ It would be completely sufficient just to reverse previous behaviour - just like it worked in version 1.8.24 - all browsers used to work fine. \ \ Thanx. \ Lubos \ → 1354540993399084 |
@scott.gonzalez
I think you misunderstood the nature of this bug - it has nothing to do with triggering the "change" event programmatically. The problem is, that the behaviour of autocomplete is completely different in Firefox, Opera and different in Chrome, IE even without trigger change event programmatically.
Unfortunatelly, it is basically impossible to fix it - unless everybody writes complex JS tests what browser is being used and then dynamically attaches events. I have spend 2 days trying various ways around - no success:-(
It would be completely sufficient just to revert previous behaviour - just like it worked in version 1.8.24 - all browsers used to work fine.
Thanx.
Lubos
Changed December 03, 2012 01:25PM UTC by comment:5
I didn't misunderstand. The change event is not useful on an enhanced widget. If you care about knowing when the value has actually changed, use the autocompletechange event.
Changed December 03, 2012 01:44PM UTC by comment:6
OK, thanx, I will try to test autocompletechange event.
Changed December 03, 2012 09:26PM UTC by comment:7
| _comment0: | Hi again, \ \ after a little of googling I found that there are many people recently confused with this behaviour considering it for a bug. Introduction of "autocompletechange" is not clearly documented and except for 2 lines of code at http://api.jqueryui.com/autocomplete/ I could not find anywhere explained or examples on what is the difference between those two events. \ \ As a web programmer, it also makes my programming more troublesome. \ For example when rendering a page, now I must test all 200 text fields "is this autocomplete field?" and bind either "change" or "autocompletechange". This is a serious performance degradation and it is a clear sign that changing this behaviour was a bad move. \ \ → 1354570248064188 |
|---|---|
| _comment1: | Hi again, \ \ after a little of googling I found that there are many people recently confused with this behaviour considering it for a bug. Introduction of "autocompletechange" is not clearly documented and except for 2 lines of code at http://api.jqueryui.com/autocomplete/ I could not find anywhere explained or examples on what is the difference between those two events. \ \ As a web programmer, it also makes my programming more troublesome. \ For example when rendering a page, now I must test all 200 text fields "is this autocomplete field?" and bind either "change" or "autocompletechange". This is a serious performance degradation and it is a clear sign that changing this behaviour was a bad move. \ \ I also do not know anything about enhanced widgets and I believe most people dont as well. What I see is a text field which used to fire change event correctly, not it works differently in various browsers. \ \ Cheers. → 1354572110089436 |
Hi again,
after a little of googling I found that there are many people recently confused with this behaviour considering it for a bug. Introduction of "autocompletechange" is not clearly documented and except for 2 lines of code at http://api.jqueryui.com/autocomplete/ I could not find anywhere explained or examples on what is the difference between those two events.
As a web programmer, it also makes my programming more troublesome.
For example when rendering a page, now I must test all 200 text fields "is this autocomplete field?" and bind either "change" or "autocompletechange". And in some situations how can a server determine if a text field of type "autocomplete" if this is only handled by a client? This is a serious performance degradation and it is a clear sign that changing this behaviour was a bad move.
I also do not know anything about enhanced widgets and I believe most people dont as well. What I see is a text field which used to fire change event correctly, not it works differently in various browsers. I like JQuery due to consistent API across all browsers. Introducing "autocompletechange" seems to me going against this concept:-(
Sorry for my unpleasant words - perhaps I would better understand if somebody could explain why the native "change" event could not be used anymore..? And is there any chance to revert it to previous behaviour? I will vote for it:-)
Cheers.
Changed August 15, 2015 02:17AM UTC by comment:8
| _comment0: | Using Jquery 1.11 and Chrome 43 and this bug seems triggering to me.. It's frustrating.. no matter the way I implement the change function is no called. \ → 1439605169626839 |
|---|
Using Jquery 1.11 and Chrome 43 and this bug seems triggering to me.. It's frustrating.. no matter the way I implement the change function is not being called.
Confirmed. Test case - http://jsfiddle.net/tj_vantoll/FDYn2/. The
event is fired upon menu selection in jQuery UI 1.8.24 but in master & 1.9.2 it does not. I saw this behavior in the latest versions of Firefox and Chrome.