'string' is also (theoretically) already supported (though let's test it just to make sure)
So valid qualifier data types: wikibase-item, quantity, string

Are we sure that we want an auto-suggest UI for the data type selection? I imagine that many users will not be familiar with the Wikibase data-types in advance – typing in an autocomplete widget might feel like taking a shot in the dark when they don't really know what they are looking for. Also, if there are only a small number of data types for them to choose between, being able to see all the available types in a dropdown menu may be useful. Will there eventually be lots and lots of options available here? Even if we supported every data type currently listed here, there are only 17 currently, which is still potentially within the limit of what someone could select from an options list.

I just want to make sure I understand the use case for this feature.

They shouldn't be able to search for datatypes, but for 'properties' (and we'll narrow it down to only properties of a certain datatype, but users don't need to be aware of datatypes)

Right now, with depicts, there a 6 (or so) pre-configured properties: color, wears, ...
For other statements, that set of properties will make no sense (and we'll also want to allow other properties to be added in depicts)
So instead of having a dropdown where they can select from this limited set of properties, we'll want to replace that dropdown with an autocomplete input field.
They can then start typing 'col' and it'll show some suggestions, like 'color'.
That's pretty much how Wikidata works for selecting properties: just start typing a property name, and it'll autocomplete, and you select one.
But because we don't have proper support for all datatypes (yet), we need to narrow it down to only properties that support certain datatypes (wikibase-item, quantity & string right now), to prevent people from selecting properties that we don't yet support.

So basically, the feature here is changing the qualifier property dropdown (with values 'color', 'wears', etc) to an autocomplete input field (that only autocompletes properties of a certain data type)
The filtering by supported data type is already implemented for 'add statement' as well (only statements of type wikibase-item can be selected there), so we should be able to lean on that work for the autocomplete.

Ah, ok, thanks for the clarification.

So as the user types, the auto-complete widget will need to search for all potentially matching Wikibase properties that match the whitelisted data-types. Those properties will be either local or remote based on whether federation has been enabled, I assume. I'll look at the way the item autocomplete field is implemented to try and adapt.

@Cparle and @matthiasmullie there are two stages to this process if I understand correctly – let me know if I'm really off the rails here.

1. The "feature-flag" stage: make minimal changes to the existing code but modify the QualifierWidget so that, if other statements are enabled, the propertyDropdown widget it creates gets replaced with an autocomplete widget. Ideally this new widget would live in a separate file entirely. This new widget won't care about the config.qualifiers values but it will need to consult some kind of config.dataTypes instead, perhaps defaulting to wikibase-item, quantity and string if none are specified.
2. The "post-feature-flag" stage: Once other statements are enabled everywhere, more significant refactoring would be in order. This would include:
   • Removing all the conditional feature-flag checking code from the previous step, as well as the code for the old dropdown widget
   • Removing all references to config.qualifiers in the Statements code and maybe elsewhere too. Some widgets expect this value to be passed in as an argument to their constructor.
   • Instead of passing in the whitelisted data-types to individual components in the same way, maybe we could create a single file or variable that read from the appropriate LocalSettings value, and other components could import it via require; I think this would be a step in the direction of making JS less inter-connected and dependencies more explicit

I will just work on the first part of this for now, but I'm happy to start a patch for the second stage once the first one gets merged.

Yep, just the "feature-flag" stage for now. I don't even think there's any need at this stage to make the data types configurable, because to add another data type will need a load of coding one way or the other ... but having said that if you want to then feel free :)

We'll have separate tickets for removal of the feature flag. I like the idea about removing global variables from the code, let's discuss that separately

Change 513538 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Allow user to set qualifier properties with an autocomplete widget

https://gerrit.wikimedia.org/r/513538

Change 515002 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Allow user to set qualifier properties with an autocomplete widget

https://gerrit.wikimedia.org/r/515002

Change 513538 abandoned by Eric Gardner:
Allow user to set qualifier properties with an autocomplete widget

Reason:
Abandoned in favor of new approach (see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/ /515002)

https://gerrit.wikimedia.org/r/513538

Change 515002 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Allow user to set qualifier properties with an autocomplete widget

https://gerrit.wikimedia.org/r/515002

This all looks good. 99% likelihood it will work flawlessly on production but I'm moving the ticket to VoP just as a reminder to make sure we look at this thoroughly when it goes live.