DataViews/Font Library: Give search fields a fixed width to stop layout shift - #80315

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: juanfra <juanfra@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: fcoveram <fcoveram@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +179 B (0%)

Total Size: 7.73 MB

_{compressed-size-action}

can we also get a screenshot of what the input looks like with a long string of text, colliding with the hidden search button? And also how that looks like when revealing the hidden button on top of the long string of text?

Thanks for looking into this 🙏

At the very least, I think we might want to avoid introducing a new Emotion-styled component, as we've documented that "new Emotion usage should not be added". Maybe it's enough to just pass a style prop with conditional visibility directly to the existing InputControlSuffixWrapper , and skip the new component?

@aduth sure thing! I missed the styling section. Actually my first attempt was to have inline styles, but then I saw we were using emotions in other spots and tried to make it consistent with that. I pushed the changes here.

can we also get a screenshot of what the input looks like with a long string of text, colliding with the hidden search button? And also how that looks like when revealing the hidden button on top of the long string of text?

@ciampo when the input has a value the reset icon is shown. So when there's content, the "X" icon will be visible. The scenario you're describing could be a possibility with long placeholders.

Before	After

^ This mockup is having the following placeholder: "This is how it looks with long placeholders". I believe this fix is more likely fixing scenarios where the searchcontrol wasn't super wide, my assumption is that long placeholders wouldn't work there either. But it's true that there's a white space at the end.

Could we tweak the width of the underlying input so that, when the input is empty (and the close button is hidden), the input spans the whole width?

My first question would be whether this is really something that should be addressed in SearchControl itself, or something that's actually fine (or better) to be addressed at the consumer level.

From a certain standpoint, if the consumer put the component in a flex layout and they care about getting that component's width to behave a certain way, they can add those constraints themselves (in this case, by putting a width or flex-basis on the SearchControl).

I'm leaning towards addressing it in the consumer, unless this is a really common pattern (which may tip the scale in favor of ergonomics). The current complexity for addressing it in the SearchControl doesn't seem too bad, but the placeholder collision is a non-negligible downside.

Thanks for catching all these layout shifts by the way! Good to see these rough edges being polished.

I just tested and the layout and interaction looks correct to me

I only noticed a small delay when after triggering the clear action that looks like a blink of the focus ring before deleting the text typed.

Thanks a lot for the reviews!

If the placeholder issue is non-negotiable, moving the fix to the clients means using arbitrary widths, can't think of other way around it. The main places this bug shows up are dataviews (several screens) and the install fonts screen. If we go with arbitrary widths we could try using some design tokens. Would look different than what it looks now, but maybe it's worth considering.

Separately, found a pre existing issue in SearchControl. The right padding for the input is set to 4px whenever a suffix is passed, regardless of whether it's actually visible. So a long placeholder with no button showing looks cramped on the right vs. the padding left on the icon (not the button but the search icon in this case). Will open a separate PR for that one.

No strong opinion on whether a width token is necessary, but I think setting an appropriate width constraint based on the the given layout is a good idea to begin with in these flex layouts, regardless of the clear button issue.

The idea holds even if we were talking about a plain input field inside a space-between container, instead of a search field. There's no intentionality to the default width a raw input element takes anyway. The consumer can (should?) set an appropriate default width based on the use case.

Thanks! Going with this then. I updated the PR title and description to better reflect what we're finally doing here. Regarding the fix, picked values that are close to what was already rendering there, so it shouldn't look really different, just stop resizing.

@fcoveram could you please re-check this and confirm the sizes are good? 🙏 The best way to test this out would be:

1. Go to Appearance > Fonts > Install Fonts (authorize google fonts if necessary)
2. Type something into the "Font name..." search input and confirm the input doesn't change width when the X button shows.
3. Remove what's in the input confirm it doesn't change the width.
4. Open a DataViews screen (e.g. Pages/Templates/Patterns in the Site Editor), type into the search field and confirm the same, no width change.

The delay you mentioned in your previous comment should be unrelated to this fix, we can probably investigate that separately.

Flaky tests detected in 3de7116.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29566420105
📝 Reported issues:

• [Flaky Test] Should save the changes #78689 in /test/e2e/specs/editor/plugins/wp-editor-meta-box.spec.js

Thank you all! Merging to fix the layout shift issue.