autocomplete fails when new widget 'jqn.menu' is created

This is as designed. The autocomplete widget depends on ui.menu via $.fn.menu. That way you can provide your own $.fn.menu and it will depend on it instead of the one that lives at $.ui.menu. If you want your own menu that doesn't fill that role, give it a different alias in the $.fn. namespace with $.widget.bridge and then use bridge to restore the $.fn.menu -> $.ui.menu alias:

$.widget.bridge( "jqnMenu", $.jqn.menu );
$.widget.bridge( "menu", $.ui.menu );

This assumes you load autocomplete (which includes ui.menu) first, then jqn.menu. If you load jqn.menu before autocomplete then only the first line above should be needed. If you have additional questions about this, please ask on the forum http://forum.jquery.com/using-jquery-ui

For more on the widget bridge, see http://www.erichynds.com/jquery/using-jquery-ui-widget-factory-bridge/

Even though I believe this is as-designed today, it's something I think we should consider fixing in a future major release. I've added a comment to that effect on the Widget factory wiki page: http://wiki.jqueryui.com/Widget-factory#commentnum1308445289 . Feel free to follow up there.

I was thinking about this problem and I think I came up with a reasonable solution. this could would reside in the jquery.ui.widget.js file right after the var _remove line.

$.fn.extend({

widget: function (name, options) {

var parts = String(name).split('.'), namespace = parts[0], name = parts[1], _widget = $[namespace][name];

/* when calling into a namespace in order to set the /*this*/ variable we have to instanciate a new instance of the widget. could we pass a reference to the widgets prototype? if we did does it risk corruption of that widget's class?*/

if ($.isFunction(_widget)) {

_widget.call(new _widget(), options, this);

/*_widget.call(_widget.prototype, options, this);*/

}

return this;

}

});