Skip to main content

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 tj.vantoll comment:1

status: newopen
summary: Change event not triggered in IE, ChromeAutocomplete: change event not fired on menu selection

Confirmed. Test case - http://jsfiddle.net/tj_vantoll/FDYn2/. The

change
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.

Changed December 03, 2012 12:56PM UTC by scottgonzalez comment:2

resolution: → wontfix
status: openclosed

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 scottgonzalez comment:3

Changed December 03, 2012 01:21PM UTC by lubosdz 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 scottgonzalez 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 lubosdz comment:6

OK, thanx, I will try to test autocompletechange event.

Changed December 03, 2012 09:26PM UTC by lubosdz 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 winchester 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.