Question about this ticket: I see that when the user initially focuses the input for the first time after pageload, the input immediately shortens, leaving more space between the Wikipedia icon on the left and the text input. Subsequently focusing or unfocusing the input after this first focus has no effect. Is this desired behavior? Should we be attempting to fix that in this ticket?

In T384391#10483926, @Millipede88 wrote:

Question about this ticket: I see that when the user initially focuses the input for the first time after pageload, the input immediately shortens, leaving more space between the Wikipedia icon on the left and the text input.

To clarify, "the input immediately shortens" is actually the bug. The expansion of the search box when a letter is entered is expected. I will update the task description now.

@Jdlrobson-WMF can you provide browser + OS info? I can't repro this on macOS Chrome

Here is @Jdlrobson's original task description for reference:

This appears to be an issue with Codex rather than Vector 2022 and seems to relate to this CSS: https://gerrit.wikimedia.org/g/design/codex/+/629d36237216249ee2237501b9a3267b72436747/packages/codex/src/components/typeahead-search/TypeaheadSearch.vue#790

Steps to replicate the issue (include links if applicable):

• Visit https://en.wikipedia.org/wiki/Main_Page
• Focus search
• Type the letter A

What happens?:
The search input expands to the left

Screen Recording 2025-01-13 at 4.36.25 PM.mov237 KBDownload

What should have happened instead?:
No expansion

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

To clarify: the expansion is intentional. This was a compromise we made so that in the unfocused state the space around the search icon would match Codex standards for inputs with icons, but then in the focused state with results below the text in the input would align with the search results text.

Search box expands to the left when results appear to make space for the image thumbnails without loosing alignment between input text and search results text

Thank you for the clarification, this is super helpful!

Have we confirmed this is an issue in Codex? We haven't touched this component in a while so I'm wondering where the regression came from.

@AlexHollender-WMF this feels a very different bug after the rewrite and I was a bit confused. Confusingly I couldnt' reproduce this until I opened an incognito window.

@CCiufo-WMF let me know if you can't reproduce in incognito - I refreshed the steps - when the input is focused the following rule gets applied:

.cdx-typeahead-search--show-thumbnail.cdx-typeahead-search--auto-expand-width:not(.cdx-typeahead-search--expanded)

I think the issue here, is that we only load Codex TypeaheadSearch component when the input is focused and this rule needs to be loaded on page load. Probably a regression of https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1084910

I think this gets back to the issue we discussed a while back that Codex TypeaheadSearch styles need to be split into

1. styles that are needed on page load
2. styles that are needed for the results

On short term we could copy across this rule to Vector 2022 but on long term I'd like to be able to load this as a component without downloading the bulk of CdxTypeaheadSearch styles which relate to the search results themselves.

This only impacts anon users (so use an incognito window!)

This happens to me logged in as well. I've attached a video showing it.

In T384391#10493654, @Jdlrobson-WMF wrote:

@AlexHollender-WMF this feels a very different bug after the rewrite and I was a bit confused. Confusingly I couldnt' reproduce this until I opened an incognito window.

@CCiufo-WMF let me know if you can't reproduce in incognito - I refreshed the steps - when the input is focused the following rule gets applied:

.cdx-typeahead-search--show-thumbnail.cdx-typeahead-search--auto-expand-width:not(.cdx-typeahead-search--expanded)

I think the issue here, is that we only load Codex TypeaheadSearch component when the input is focused and this rule needs to be loaded on page load. Probably a regression of https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1084910

I think this gets back to the issue we discussed a while back that Codex TypeaheadSearch styles need to be split into

1. styles that are needed on page load
2. styles that are needed for the results

On short term we could copy across this rule to Vector 2022 but on long term I'd like to be able to load this as a component without downloading the bulk of CdxTypeaheadSearch styles which relate to the search results themselves.

I am able to reproduce it now, yeah. Why did we decide to stop rendering TypeaheadSearch styles on page load? Was the payload getting too large? I don't think DST was really aware of https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1084910

Adding to web team board, so we don't forget to consider whether we want a short term fix here.

Created a subtask for web team.

I'm still seeing the issue in production

@AlexHollender-WMF are you only seeing this in a private browser window? I think this is just a caching issue and hasn't caught up to all users yet.

a few clarifications

1. This is not deployed in production yet. There was a deployer blocker so 1.44.0-wmf.20 train hasn't rolled out to English Wikipedia yet.

2. @CCiufo-WMF this task is still open - we want to find a long term solution for this. Right now web has to keep the styles synced with Codex so there is a possibility this will break again in future. Right now requesting styles for CodexTypeaheadSearch pulls down lots of styles that are not necessary until the typeahead search component is interacted with (such as the menu component for search results). I would expect the correct solution here to break the existing TypeaheadSearch component into two comments: perhaps TypeaheadSearchInactive and TypeaheadSearchActive or TypeaheadInput and TypeaheadSearchResults.

In T384391#10633883, @Jdlrobson-WMF wrote:

a few clarifications

1. This is not deployed in production yet. There was a deployer blocker so 1.44.0-wmf.20 train hasn't rolled out to English Wikipedia yet.

Sigh, I was not testing with my browser set to the correct width to reproduce the bug, sorry about that.

2. @CCiufo-WMF this task is still open - we want to find a long term solution for this. Right now web has to keep the styles synced with Codex so there is a possibility this will break again in future. Right now requesting styles for CodexTypeaheadSearch pulls down lots of styles that are not necessary until the typeahead search component is interacted with (such as the menu component for search results). I would expect the correct solution here to break the existing TypeaheadSearch component into two comments: perhaps TypeaheadSearchInactive and TypeaheadSearchActive or TypeaheadInput and TypeaheadSearchResults.

I recommend spinning out a new task to tackle that as known tech debt, because IMO this task should be resolved as soon as the bug is no longer visible to users.

I opened T388845 for the long term fix.
Merging this one into T385515