This appears to happen because the input widget inside the titles multiselect widget is wider than the max width of the titles multiselect widget at first.

Are we planning to reinstate this once T211048 is resolved?

Just pointing to T211048, where we're auditing the affected classes - any feedback very welcome!

This is affecting the TitlesMultiSelectWidget on Special:Block too (with partial blocks enabled).

Unless @dmaza disagrees, I don't think any of these options should be particularly complex.

In T210475#4795055, @TBolliger wrote:

I think we'll go with your middle proposal — [change] #2.A to say that the Page input containing the target's talk page should instead act like the checkbox was checked

I've updated the list of classes that don't explicitly override requiresUnblock to state the return value that they inherit (see above).

@Anomie Good point. searching "extends.*<className>" throws up one more result (PurgeAction in Flow) - updated the list above.

Method

1. Search: https://codesearch.wmflabs.org/search/?q=requiresUnblock&i=nope&files=&repos=
2. For each class where requiresUnblock returns false, search "extends <className>"; do this iteratively for all descendants until no more results

This also affects sitewide blocks in the same way.

@Ryasmeen Oops looks like I forgot to push the change - thanks for pointing that out!

Here are some screenshots in the different skins with that patch:

Special:ActiveUsers task filed as T210391

Do we want to do the same for Special:ActiveUsers?

In T209630#4765596, @Tchanders wrote:

It seems there are two points at which we need to show the loading bar:

1. while the JS widget is loading, if the user has JS
2. while the menu is loading, after the input has been changed
   
   After speaking to @Mooeypoo it seems this task is about point 2

It seems there are two points at which we need to show the loading bar:

1. while the JS widget is loading, if the user has JS
2. while the menu is loading, after the input has been changed

Looks like this isn't actually an exact matching problem, or anything affecting 1-character titles exclusively.

In T206534#4745136, @Ryasmeen wrote:

2. Sometimes I am seeing the "Apply changes" button staying enabled even if there hasn't been any changes (Haven't found the exact steps yet for this, trying to).

The 'limit' value (renamed 'tagLimit' in T209057) is passed through in the patch on T208626.

@Ryasmeen Is it possible you're looking at inspectors? The extension dialogs are graph, math[1], chem[1], maps, syntax highlight and pre. These and other dialogs should all have "Apply changes" - do you see those?

Thanks for the feedback.

After talking to @iamjessklein yesterday and in light of @Esanders' comments above, I've put something together along those lines:

With the narrower inputs, there's no wrapping on a 320px-wide screen, and 4-digit numbers fit comfortably.

While looking into this, I noticed the spacing between elements is affected by whether we have fieldset->widget or fieldset->field->widget. It's also affected by whether we use addItems() or append one element to the other. We should use these components properly to get a predictable appearance, and if there's a need to deviate, we should comment why.

Thinking more about point (4), that layout looks pretty crowded on a mobile screen: