This thread has become a little long an confusing.

In T215644#5261722, @Cparle wrote:

Erm ... I think we're using the framed one, would be nice if it wasn't deleted

It's pretty easy to fix (patch up for review), but:

• this is default Firefox behavior
• and while OOUI adds its own in-/decrease controls, it doesn't override that behavior

I'm not sure whether or not there's a good reason that this is not already handled in OOUI, so pinging @Volker_E for input.

Is there any consistency between devices/browsers? Has this been seen anywhere other than Opera? (I've never had it on Chrome and have not used other browsers extensively)
Since a hard refresh fixes things, I'd guess the browser caches too aggressively (or we instruct it to, with poor HTTP cache control headers)

Oops! I messed up the order of add/focus operations, causing focus to stop working. Patch up, will be fixed shortly!

@PDrouin-WMF: Are we also ok with the dropdown having the length of the input field + delete icon?
(because I'd otherwise have to subtract the icon's size from the dropdown's length, but that's defined in OOUI and could change beyond our control)

It looks like mw.config.get( 'wbDataTypes' ) already holds this map!
wbDataTypes won't exist on Special:UploadWizard, but we should probably let WikibaseMediaInfo expose a similar (or the exact same) map, in the same way it already does wbmiProperties (and a few others) so that they're always available, even for UploadWizard.

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.

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)

I think Eric is referring to the input field for selecting a new property, like this:

Actually, let's move this to "Verify on Production", since there's nothing new to test, and the example (and fix) are already in prod.

Yes, should be fixed already. Moving to Needs QA for verification.

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

Most of that code is somewhere in WikibaseMediaInfoHooks::doBeforePageDisplay (and the various methods called from there)
That method is run via a hook shortly before everything gets output.
Basically, the content is already there (from parser cache, or generated at that time) and the code in that method will extract it from that location, do some things with it (e.g. add tabs) and move some bits and pieces around.
All of that happens after the parser cache, so should probably be fine.

That's because the captions panel is inside <div id="mw-imagepage-content">, which has lang="en", dir="ltr" and class="mw-content-ltr".
It makes sense that that one has LTR, because it indicates the start of the "content" of the page (not the interface), which on that page, on Commons, is English.

@WMDE-leszek that worked, thanks!

As I understand it, when doing async uploads:

I suspect "cancel/publish" should be in the same row as "add a caption" if there's enough space, and drop down below it if the screen becomes too small to fit all
(that's how it's done for statements, with "remove statements/learn more" instead of "add a caption")

https://federated-commons.wmflabs.org/wiki/Main_Page (also added to acceptance criteria)

Oh cool - didn't know you could list properties by value datatype - might already have a few I won't need to create!

The first (wikidata logo) has a patch already: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/510721

Assigning to @PDrouin-WMF to verify this is fixed.

Assigning to @PDrouin-WMF to verify this is fixed.

This ticket is about both captions & statements.

"first attempt to edit", is this:

• every time one goes into edit mode, not for any other change after that
• only when user goes into edit mode for the first time for this statement
• only when user goes into edit mode for the first time for any statement (= if this was already displayed for another statement, we're not showing it again)
• only ever once, for statements OR captions, for whichever is first (making changes to captions, statements, captions again, ... = still only one notification for the very first change, and none after)

The properties have the wrong value datatype.
They're all 'string' (which is why it's just a plain input field), but it should be 'Item' for most, and 'Quantity' for quantity.

I have no permissions to edit this gadget, so...

It works! Thanks

The actual issue here is that UW was configured to allow 255 characters (and it shows and continues to show a warning when you exceed that number), but Wikibase doesn't allow labels longer than 250 (not 255).
So anything with 251-255 characters ran into this issue...