[…] help teach/remind the users […] about the problem and solution.

Yes, this needs fixing. The behavior is confusing. Instead of 1 there are 2 breakpoints now: 1.) The width becomes flexible when the dialog starts touching the window. 2.) The height changes from 90% to 100% for no apparent reason.

What the keywords "medium" and "large" originally mean is specified in OO.ui.WindowManager.

• "medium" is { width: 500 }
• "large" is { width: 700 }
• "larger" is { width: 900 }

Some quick investigation results:

• I'm able to run these tests locally with no problem.
• When I put Reference Previews back in Beta mode, the tests are skipped. No failure.
• When I enable a conflicting gadget, the tests fail, but with a very different error (element (".mwe-popups") still not existing after 10000ms).
• The failure described in this ticket happens because the ResourceLoader module ext.popups.main never loads.
• This can actually happen when a registered user disabled both Page Previews as well as Reference Previews. However, the test forces the popupsreferencepreviews option to be enabled.
• … since T281235 there are 2 options. popupsreferencepreviews while in Beta, and popups-reference-previews after Beta. That might be it.

We currently don't have plans to pick this ticket up. The impact is very low. We don't know much about the code and the ticket that introduced it (T269336). I gave it a try (as I always do) to see if I can come up with an easy 1-line fix, but wasn't able to. Would be great if you could put this in your backlog.

Footer is always available.

Only when at least one of the popup types is disabled.

[…] causes invisible "Cancel" text to be highlighted […]

As written at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FileImporter/+/683860 this is not relevant on the Wikimedia cluster. The $wgFileImporterRequiredRight config is set to "upload" by default, but the upload right is checked anyway, independent from that config. The config was introduced for 2 reasons:

• To be able to quickly change it in case there is a legitimate reason to limit the user group allowed to use the special page.
• For 3rd party installations.

While this is a legitimate bug, it does not allow to bypass the upload restriction. Therefor I think this does not need to be market as a restricted security issue.

It's done: https://he.wikipedia.org/wiki/Special:Diff/31279543

Here is a code snippet everybody can copy-paste to their own https://de.wikipedia.org/wiki/Special:MyPage/common.css page in case they want to hide the line numbers.

I posted a request on the user page of the user that appears to be the main author/maintainer of the gadget: https://he.wikipedia.org/wiki/Special:Diff/31276698. Let's wait a few days for a response now, but ideally not longer than May 5th, see T271206. Alternatively we could contact one of the other users that edited the page.

According to my first git bisect in the Popups codebase this issue exists since the very first patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Popups/+/571465/ (T236097, April 2020) that enabled Page-Previews on mobile.

I'm not working with these codebases any more. But since I created this ticket once, I had a quick look at some random codebases I could find.

Quick investigation: Page previews are enabled on mobile since T236097: Dev: Popups modules should set targets to mobile and desktop. So the fact that we end here is intentional. The icon might have been broken because of some CSS optimizations we did while working on ReferencePreviews. Let's do a git bisect to see if a specific patch pops up.

The fact that ReferencePreviews are listed in the dialog is clearly a bug. Since T243822: Reference -Preview and -Popup shown both with Minerva in desktop mode ReferencePreviews are unavailable in the mobile skin (a.k.a. Minerva). In the patch https://gerrit.wikimedia.org/r/680293 (T277640) we introduced a 3-state model where null means a popup type is not available. We forgot to pass this information to the settings dialog. As of now the only thing the settings dialog respects is the BetaFeature flag, but not if there is a conflict with the skin or a gadget.

Suggestion: Let's do a quick git bisect and see if we find a specific patch that might be responsible for this.

Next step: Message the user and ask if they can update the gadget to include both the old as well as the new setting name popups-reference-previews (see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Popups/+/682926/2/src/isReferencePreviewsEnabled.js#36).

For comparison, this is how the dialog looks right now. The checkboxes are the native ones from Chrome.

This is how it looks like with the first patch https://gerrit.wikimedia.org/r/682914:
{F34429776}

Wonderful, thanks a lot for the fast response!

While the performance on this example page is still not great, I believe it's already much better after the fixes we did in T270237. @AntiCompositeNumber, are you able to test this again and let us know if it behaves different now?

I'm sure I miss something, but why don't you use HTML + CSS then?

To be honest I don't see an issue here. This specific constraint is not new. Over the years I learned that …

1. We often forget this, but the text on a button changes with the language. This means it will be significantly longer in one language, and significantly shorter in another.
2. This means we must design all our UI elements to be flexible, no matter how long the text is. We don't want a long text to be cut off or stick out of the element.
3. What we often forget is what happens when the text is extremely short. Let's say the English button Publish changes becomes 新 in Chinese. See what happens? The button becomes tiny. It's significantly harder to hit it with the mouse – an UX issue especially for users with motor impairments. Because of this pretty much all our UI elements need some min-width.

[…] we have exceptions and ways to make the rule be ignored in certain cases

I know, but as we have seen this doesn't solve the fundamental issues. Not only is it still punishment, I pushes users in a defensive corner. Nobody should be forced to explain why they talk about e.g. "blind people" or "mastering something".

I dug a bit into what I know about SVG, as well as what the internet knows. Literally "enlarging the rectangle" when the text gets bigger is not possible, as far as I can tell. I mean, everything is possible, but only with JavaScript, not with pure SVG + CSS.

I wonder if we can make sure this is going to be implemented in a way that does not feel like punishment? Tools like codesniffers are boolean. Either a word is in the list and nobody can ever use it, under no circumstances, or everybody can. But this is not how language works. Context matters a lot.

I did a git bisect and found the responsible patch in core, not OOUI: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/673034.

While I have seen this bug before, I can not reproduce it any more with the current state of the codebase. Is this on a specific browser? Can you verify if your codebase is up to date?

There is an existing patch with extensive investigation: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Popups/+/662743

We realized that "behind a feature flag" can have a surprising large number of meanings:

1. It could mean that no UI element in VisualEditor ever shows suggested values, even if they are there.
2. … it could mean the above, plus the TemplateData wizard's UI doesn't allow to add suggested values to a field, except the field already has suggested values.
3. … it could mean all of the above, plus the TemplateData wizard's UI never shows the UI element, even if there are already suggested values.
4. … it could mean all of the above, plus the HTML table rendered on the template page doesn't show suggested values, even if they are there.
5. … it could mean all of the above, plus the TemplateData API never returns suggested values, even if they are there.
6. … it could mean all of the above, plus when there is a "suggestedvalues" field in the JSON, it is silently discarded.
7. … it could mean all of the above, plus the template can't be saved when there is a "suggestedvalues" field.

Authors MUST give suggested values which match the field type.

@Lena_WMDE: https://docs.google.com/document/d/1SCtl31pMchiUkJV1iPdPUhUNyKzDcZoVyH37pSldSTA#heading=h.acnh93ezs5as already contains a comparison matrix. I tried to come up with a more complex matrix that incorporates everything written and said so far.