This is an unintended consequence of #5120. Now that the ui-autocomplete class is correctly on the widget element - the same with the ui-widget class and the same returned by .autocomplete('widget') - the input still needs some kind of ui-autocomplete-* class. In the case of dialog, the original element gets a class of 'ui-dialog-content' but that one's a little different because it's a child of the ui-dialog wrapper element that is generated.
Datepicker is a more similar example, since it can have a text input as a trigger. As the forum post indicates, datepicker adds a 'hasDatepicker' class, but this shouldn't be followed as it doesn't have a 'ui-' prefix, nor does it contain the more specific 'ui-datepicker-' prefix. I think 'ui-autocomplete-input' would be suitable. A similar class could be added to the datepicker's input 'ui-datepicker-input' and the hasDatepicker class could be deprecated.
This is an unintended consequence of #5120. Now that the ui-autocomplete class is correctly on the widget element - the same with the ui-widget class and the same returned by .autocomplete('widget') - the input still needs some kind of ui-autocomplete-* class. In the case of dialog, the original element gets a class of 'ui-dialog-content' but that one's a little different because it's a child of the ui-dialog wrapper element that is generated.
Datepicker is a more similar example, since it can have a text input as a trigger. As the forum post indicates, datepicker adds a 'hasDatepicker' class, but this shouldn't be followed as it doesn't have a 'ui-' prefix, nor does it contain the more specific 'ui-datepicker-' prefix. I think 'ui-autocomplete-input' would be suitable. A similar class could be added to the datepicker's input 'ui-datepicker-input' and the hasDatepicker class could be deprecated.