I am not able to repro this, could you provide the size of the screen in pixels?

Sure. It's 1920 x 1080.

Also note that the scrollbar appears down below.

I'm still not able to repro it. I suspected it could be some invisible border or something that appears on focus, but setting the width exactly to before overflowing content and focusing on the textfield doesn't trigger the scrollbar. Could you recreate it maybe setting a div around it that allows scrolling?

I used the Edge Browser zoom to 150% and it appears indeed at the bottom. It disapears when you change zoom to something less, like 125%.

I'm still not able to repro it. I suspected it could be some invisible border or something that appears on focus, but setting the width exactly to before overflowing content and focusing on the textfield doesn't trigger the scrollbar. Could you recreate it maybe setting a div around it that allows scrolling?

If you're having trouble reproing, maybe try a higher zoom level (such as 200%).

Does your monitor have a native resolution of 1920 x 1080? The issue seems related to fractional pixels, so that might be a required part of the repro.

Regarding setting a div around it, I'm not sure exactly what you're asking for.

Okay I see it reproing. It looks like my guess was correct, but this happens due to this overflow style:

When the textfield is unfocused we have a width of 398.67, but when we focus we add an outline that's 2px wide causing this:

and therefore, overflowing the root where the style is applied.

Glad you were able to repro. Just to clarify: do you agree this a bug when hosting the control inside a fixed-size container? Or do you consider this by design?

@sopranopillow Just checking in again on my question above. Thanks!

Hi sorry for the wait, I actually consider this by design. The root is meant to take the size of the input, so no overflow logic should be added. We do this in v9 as well. If the goal is to let the input resize based on scroll height, that should be dealt through JS like (react-textarea-autosize)[https://github.com/Andarist/react-textarea-autosize) does.

@sopranopillow Thanks for the clarification. While investigating how to resolve this in our codebase, I realized that my repro was not consistent with what we're actually doing. We aren't setting overflow:auto on the root of the TextField. Instead, we're doing that on a div that contains the TextField.

I've updated my codepen with a new, more accurate repro that doesn't depend on any custom styling of the TextField.

If a TextField is contained in a fixed-size, scrollable container, it doesn't seem like the TextField should change its size just because it’s focused.

Can you take a look?

Hey @sopranopillow. Just following up. Do you consider the new repro I posted a bug, or by design? Thanks!

hi @ehrenMSFT, I'm not able to repro this one. I'm following the same steps as before and just to confirm I'm doing it right, I'm doing this:

• zoom to 150%
• make sure the window width is exactly the same as the window input (tried also making it little less and little more)
• focus on the input

maybe a video of the repro would help.

@sopranopillow Here's a video repro:
https://github.com/microsoft/fluentui/assets/29806264/2ebbb8f7-7c31-476b-8778-936714389877

My steps were:

• Set the Windows "Scale and layout" zoom level to 150%.
• Leave my browser window width maximized.
• Focus the text field.

Hi @ehrenMSFT, I've tried to repro this and got some of the other contributors to try it as well and we weren't able to repro it. FWIW I do think this would be a by design case.

@sopranopillow Ok, thanks for checking. Regarding this being by design, what is the recommendation for hosting these controls inside a fixed-size, scrollable container, since their size changes when they're focused?

We're getting bugs filed against our application, due to customers using various zoom levels that cause these scrollbars to appear.

I was able to repro the issue! For me, it happened on Edge on Windows at 175% zoom. The cause was Edge calculating the ::after pseudo-element's width as 0.29px larger than the root node 🤦🏻‍♀️.

I'm pushing a fix that adds overflow: hidden to the element with the ::after focus style.

@smhigley Awesome! Thanks for fixing it.

Because this issue is marked as by design and has not had activity for over 3 days, we're automatically closing it for house-keeping purposes.

I don't think this is considered By Design anymore. There's an open PR out that's intended to fix it.

Hi @smhigley. Just curious what the status of the fix is. Thanks!