The same issue exists on the English Wiktionary mobile site as seen here. The button is supposed to say "Look up".

Archive template on Commons as well

I think these are all using the InputBox extension, which was converted from mediawiki.ui to Codex in T353371. I'm not sure if the early/unnecessary truncation is happening at the Codex-level or extension-level. Someone from Design-System-Team will take a look.

This is a flexbox thing, and is not specific to InputBox - it could happen anywhere a button is used in a flex layout. It's also not related to the text truncation within the Button component.

The issue here is the Button component's min-width, which is set to 32px to ensure that buttons, even at smaller font sizes and especially for icon-only buttons, never shrink below that width (and, in the case of icon-only buttons, never lose their square aspect ratio). This has an unexpected consequence in flexbox though: typically, a flex-item won't shrink below its content width, but setting a min-width that is smaller than the content width means that the flex item can shrink to that min-width. So, counterintuitively, by adding the min-width, we are decreasing the width of the flex item.

There are a few ways we could solve this:

1. Only apply the min-width style for icon-only buttons. We'd need to test that icon-only buttons would still look right in a flex layout, and confirm that we don't need the min-width for text buttons.
2. Add flex-shrink: 0 to the Button styles, which will mean buttons will never shrink beyond their content width. We actually do want text truncation for buttons with very long text, though, so we'd need to account for that somehow, without breaking non-flexbox uses. I'm not sure how we could do this in a way that works for all use cases.
3. Do nothing in the Codex component, and instead document how to handle this within features. There are a few flex styles you can consider depending on your needs to either prevent the button from shrinking, remove the min-width, or ensure the other flex item(s) only take up space after the button claims its own.
4. Other options? It would be nice to handle this within the Codex Button code so users of the component don't have to think about it.

I'm hoping option 1 is viable but am curious to know if anyone has other ideas.

@AnneT Thanks for the writeup! Could we prototype Option 1 you describe so that we can play with it and at least preliminarily decide if it's the direction we want to go with? Is that within scope of the 3 pts? Assuming there are no glaring issues, we can then think about a more thorough testing plan.

@CCiufo-WMF yes, and I plan to talk to the engineering team about this tomorrow during our synchronous meeting. We'll want to think through the potential for regressions and a testing plan, as you said.

In T370032#10004837, @AnneT wrote:

@CCiufo-WMF yes, and I plan to talk to the engineering team about this tomorrow during our synchronous meeting. We'll want to think through the potential for regressions and a testing plan, as you said.

Okay perfect!

Change #1056226 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] docs: Add test cases for button flex behavior

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

Change #1056227 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] Button: Remove min-width for non-icon-only buttons

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

@egardner @Volker_E I've got patches up for Sandbox demos and a fix. Pixel testing also needs to be done.

Test wiki created on Patch demo by EGardner (WMF) using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/c019f24adf/w

I think I found one place where removing the min-width from all buttons might cause a bit of a UI regression.

In the Growth Mentor Dashboard, there are some custom button groups which allow the user to control filters for part of the UI. The options are single-digit numbers for days/months. These are regular buttons (not icon-only ones) with only a single character as the text.

Removing the min-width produces the following layout (which is probably not ideal):

If there are any other single-character buttons out there, this might come up again.

I don't think that this is a huge problem however. I would be happy to move forward with this patch if we just gave folks a heads up (and maybe added some content to the Button guidelines) telling developers that they should consider adding a min-width: @min-width: @min-size-interactive-pointer; to any buttons where the label is only 1-2 characters long.

Change #1056226 merged by jenkins-bot:

[design/codex@main] docs: Add test cases for button flex behavior

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

Change #1056227 merged by jenkins-bot:

[design/codex@main] Button: Remove min-width for non-icon-only buttons

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

Change #1060504 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/core@master] Update Codex from v1.10.0 to v1.11.0

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

Test wiki created on Patch demo by EGardner (WMF) using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/e5da39d6d5/w

Change #1060504 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.10.0 to v1.11.0

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