#7229 closed bug (notabug)

Opened April 08, 2011 11:43AM UTC

Closed April 08, 2011 12:18PM UTC

Last modified April 08, 2011 01:04PM UTC

wrong widget event binding on creation

Reported by: akoptsov Owned by:
Priority: minor Milestone: 1.9.0
Component: ui.widget Version: 1.8.7
Keywords: Cc:
Blocked by: Blocking:
Description

error in handler functions call

when using a code like this

<html>
	<head>
	    <link type="text/css" rel="stylesheet" href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.7/themes/base/jquery-ui.css"></style>
		<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>
		<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.7/jquery-ui.min.js"></script>
		<script type="text/javascript">
			$( function(){
					var elem = $('#elem');

					elem.autocomplete({
						minLength : 0,
						source: ['1', '2', '3', '4', '5'],
						select : function(event, ui) {
						   alert('foo!');
						}
					});

					elem.bind('autocompleteselect', function(event, ui){alert('bar!');});
					
					// on automatic 'autocompleteselect' trigger (using autocomplete from UI)
					// both handlers will fire

					// If we manually trigger selection
					elem.trigger('autocompleteselect', {});
					// the first handler won't fire - however, the second will
				}
			)
		</script>
	</head>
	<body>
		<input type="text" id="elem">
	</body>
</html>

the problem resides in ui.widget's _trigger function which treats both kinds of events separately.

var callback = this.options[ type ];

doesn't consider that 'type' can be not only full name, but also shorthanded.

Solution : if 'type' starts with widget event prefix - should crop event prefix from the beginning of type variable before accessing properties

Attachments (0)
Change History (7)

Changed April 08, 2011 12:06PM UTC by akoptsov comment:1

jsFiddle ref:

http://jsfiddle.net/akoptsov/AKfv2/

Changed April 08, 2011 12:18PM UTC by scottgonzalez comment:2

resolution: → invalid
status: new → closed

Manually triggering a widget's events isn't supported.

Changed April 08, 2011 12:24PM UTC by akoptsov comment:3

Replying to [comment:2 scott.gonzalez]:

Manually triggering a widget's events isn't supported.

OK, but if it's technically possible - shouldn't it at least be unambiguous?

Changed April 08, 2011 12:25PM UTC by scottgonzalez comment:4

It is defined, you're triggering an event and all event handlers are executed. The callback that you pass as an option is not an event.

Changed April 08, 2011 12:56PM UTC by akoptsov comment:5

You are most probably right, but I still don't understand one thing:

What's the purpose of passing callbacks as options if not for them to be triggered on events?

Either that, or _trigger function in ui.widjet.js treats these two concepts separately for a reason. And if you know that reason - please tell me :)

Changed April 08, 2011 01:01PM UTC by scottgonzalez comment:6

The callback options are a convenience. Users are never supposed to trigger a widget's events manually because it will likely cause an incorrect state. This is not a discussion that should occur in the bug tracker. If you have actual use cases that you want to discuss, please start a thread on the forums.

Changed April 08, 2011 01:04PM UTC by akoptsov comment:7

Ok, thanks for the directions.