Hi @jwang! I was hoping to access data about skin usage and saw that the dashboard linked in the task description is gone - is there any way to get a fresh set of data?

@Edtadros This appears to be a caching issue on the main page. I was checking https://en.wikipedia.beta.wmcloud.org/wiki/Special:Version to confirm that the version of Vector is the latest commit to master, and the autocomplete attribute is there in the server-rendered version of the input on that page. Can you try testing there?

@Edtadros hmm, it looks like beta wikipedia is on a commit from last Thursday, so it doesn't have the commit from the patch that fixes this bug (I inspected the server-rendered input and it doesn't have the autocomplete="off" attribute). I'm going to look into why beta isn't on the latest commit in master.

@Edtadros / @Etonkovidova please let me/the team know if you'd like some info on setting this up locally for testing purposes. This needs to be tested in tandem with this patch, which covers T395861 and T396673, so you may as well wait for that to be finished.

Hey @Edtadros, I think you were working on the mobile search stuff with Web before they disbanded, but if you need more info to test this please let us know.

@bwang Feel free to add an estimate and move this to the sprint board!

@Catrope maybe the CSS-only component should be removed from this task and moved to a new one?

@ovasileva I'd recommend we add 3 points for code review and put this in "ready for sprint" so we can pull it in if we have time, once Roan has created the patch. Does that work for you?

Hi @Vanshika! Thank you for your patch for this task. I'm sorry for the confusion, but we probably shouldn't have marked this with the good first task tag - we're still determining the best way to handle styling this button.

I checked again and can't reproduce it now that the latest version has been deployed to frwiki; closing!

In T396941#10991738, @Reedy wrote:

Using these instructions (noting I don’t use docker for MW) https://gerrit.wikimedia.org/g/mediawiki/core/+/HEAD/DEVELOPERS.md

I'm having the same issue on a Mac with a fresh install.

Thanks everyone for reporting this and @ekrem for the workaround - I've applied that fix in the Codex Message component.

The hyphenation part of this issue is resolved now that Codex v2.2.0 is merged into core. I've opened a separate task for the message icon that's cut off.

@SLyngshede-WMF we've removed most CSS hyphenation as of Codex v2.2.0, so if you update to that version this issue should be resolved.

You could change max-height to @line-height-small as well - we use line height tokens for heights in a few places in the library, although this one is slightly less justified since we're not trying to match the height with the line height, it's just a coincidence that the line height token is exactly what we need. Otherwise, you'd need to add a new size token. I'm not sure if that's preferable - I feel like we limited the size token scale for consistency's sake.

The effective height at the medium font mode is currently 22px, which seems to be too small, and we should never set max-height in pixels anyway (current max-height is 1.5rem which works out to 24px). Setting the line-height to @line-height-small (1.375rem) seems to resolve the issue without exceeding the current max-height.

I've added 2 new patches to try to move this WIP component forward:

• The first one updates the code to match patterns in the rest of the Codex library and refactors the docs page to match the new format.
• The second one is a proof of concept to use CSS to truncate text rather than setting a character limit, which may have been problematic across languages.

hey @bmartinezcalvo, could you please check the remaining acceptance criteria and close this if they're done?

For now, we decided to remove CSS hyphenation except for German and related languages. We can add more languages in the future if hyphenation is beneficial for them.

DST engineers decided to close this task since the inconsistent flipping issue has been resolved, and @Catrope will open a new task for the MediaWiki header (and Codex sandbox sticky header) overlapping the flipped menu.

DST engineers discussed this today and determined that the existing behavior matches the design. Menus within Dialogs should overflow the Dialog body, even extending on top of the Dialog footer and beyond the Dialog container. There are a couple of reasons for this:

• A long menu shouldn't cause the Dialog body to grow vertically or add scrolling when the menu is opened - this would be jarring.
• An open menu should take visual precedence over other elements, like the Dialog action buttons. The menu should be interacted with or closed before the user proceeds to the action buttons.

The DST engineers discussed this today and @Catrope will determine whether this can be resolved by teleporting menus as part of his investigation of T379836. I created a proof of concept to solve this issue in Tables as a CSS-only solution if we decide not to teleport all menus.

This task has been recently resolved and will be closed after the next Codex release

@CCiufo-WMF yeah, it's only when you don't have thumbnails enabled (which will be true on wikidata)

1. It says 'Use Bold weight by default. Normal weight is permissible in some specific cases to blend more with surrounding texts.'. Does this mean we need to support setting a weight via props?