Microsoft.Maui.Controls 8.0.90 (Latest stable) Ruins Entry Controls

[Dannyk90]

Description

If you update the Maui Controls NuGet to the latest stable (currently 8.0.90), all Entry controls become very narrow and nothing will fix it apart from downgrading, I just went back to 8.0.72 and it is fine again.

This appears to only affect Windows. Not IOS or Android.

Steps to Reproduce

1. Create a new MAUI project
2. Add an Entry control to the home page xaml.
3. Launch and see that it looks fine
4. Upgrade the Maui Controls NuGet to the latest stable 8.0.90
5. Launch project again and see that the Entry looks awful now.

Link to public reproduction project repository

No response

Version with bug

8.0.90

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

8.0.72

Affected platforms

Windows

Affected platform versions

Windows

Did you find any workaround?

Downgrading the NuGet

Relevant log output

No response

[github-actions[bot]]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• Entry tab "stretching" bug. (#15783), similarity score: 0.75
• [regression/8.0.0] Entry bug—height grows on every input event (#18092), similarity score: 0.74

Closed similar issues:

• MAUI Entry Control Font Stability (#16743), similarity score: 0.76
• Windows: Entry with right aligned text keeps text jumping to the left during editing (#24405), similarity score: 0.76
• Entry Layout broken after Update .NET MAUI to 7.0.81 (#14562), similarity score: 0.75

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[MartyIX]

I can see

Version with bug

9.0.0-rc.1.24453.9

That's a bit confusing.

[MartyIX]

Also a screenshot comparing the new and the old behavior would be very helpful here.

[Dannyk90]

That's a bit confusing.

Yep, unfortunately, the NuGet Project Url is just for Maui, not a specific project url for this NuGet, and that field was mandatory.

Older Version Behaviour:

New Version Behaviour:

[bronteq]

@MartyIX 8.0.90 is not yet available in the issue template

[MartyIX]

@MartyIX 8.0.90 is not yet available in the issue template

I see. The issue van be post-editted then.

[baaaaif]

Can confirm this on our App. SR9 cannot be used at the moment. Editor does not have this bug.

[MartyIX]

Interestingly, I don't observe this behavior in my app.

[PureWeen]

Interestingly, I don't observe this behavior in my app.

Yea, @Foda and I both tested this as well and couldn't reproduce

I realize the repro steps seem simple, but if you could still attach a repro just so we can validate that would be helpful.

[Dannyk90]

@PureWeen , I can no longer recreate the problem. I have since updated visual studio and the .net sdk (to fix another issue). @baaaaif maybe you can try updating those too and see if that resolves it for you too

[baaaaif]

ok, this one took me some time. I can reproduce it with simply adding a reference to <PackageReference Include="Telerik.UI.for.Maui" Version="7.1.0" /> without even using .UseTelerik() in MauiProgram

really strange... may you've had this too, @Dannyk90 ?

[Dannyk90]

@baaaaif , the problem does happen again if I install Telerik NuGet and put .UseTelerik() in MauiProgram.cs

[baaaaif]

@TelerikMauiTeam sorry for pinging, but might be in your interest

[ninachen03]

This issue has been verified using Visual Studio 17.12.0 Preview 2.0(8.0.90 & 8.0.80 &8.0.72). Cannot repro this issue at windows platform. By the way,I can't use the Telerik.UI.for.Maui,Is there anything special about it?

[drasticactions]

This issue has been verified using Visual Studio 17.12.0 Preview 2.0(8.0.90 & 8.0.80 &8.0.72). Cannot repro this issue at windows platform. By the way,I can't use the Telerik.UI.for.Maui,Is there anything special about it?

Yes, they are not on Nuget, I believe you need to download them from Telerik's website

[Dannyk90]

Telerik have their own NuGet source

[cmpalmer66]

I verified that, starting from a fresh templated project and updating Maui to 8.0.90, the problem did not appear until I added a reference to Telerik's UI for .NET Maui 7.1.0.

Before:

After adding the Telerik Nuget package (but not adding UseTelerik() to the Builder):

I've attached my sample project with the Telerik reference. You can run it to verify that the problem only appears on WinUI and goes away when the Telerik reference is removed. WinUIEntryBug.zip

[PureWeen]

I'm going to close this issue for now unless I hear otherwise from Telerik

Can you create an issue using their support system and reference this issue?

[cmpalmer66]

I did create an issue for Telerik. I am curious as to the cause, though, because the problem arose on the release of Maui 8.0.90, not on the release of the Telerik 7.1.0, which has been out and working for a while.

https://feedback.telerik.com/maui/1665106-version-7-1-0-and-maui-version-8-0-90-break-sizing-of-winui-entry-controls

[malsabi]

When I updated to MAUI 8.0.90 I had the same Issue and I was not using Telerik. Maybe this issue happens when you attempt to make the Entry borderless? cause my entry is borderless by setting BorderThickness to 0 for Windows platform. I had to downgrade back to 8.0.80

[LanceMcCarthy]

HI Shane, it is a holiday in Sofia today, but I'll make sure the team take a look at it tomorrow morning (about 1 am Redmond time tonight) follows up in that public item once there is a determination.

@malsabi This is a very important insight that could swing the investigation in the right direction. When adding the Telerik package, you are applying some standard implicit styles, and there are 0-width BorderThickness values in the styles. Can you please share the XAML (and any associated Style) for the Entry that is affected?

[edit] Fixed misspellings

[LanceMcCarthy]

[!Note] Disregard this finding for now, I'm seeing a different behavior each time I check a different style. I need to leave this up to the dev team to dig deeper and find exactly where the influences are coming from. Thanks for hanging in there while they work on it.

Hi @PureWeen, I can reproduce the issue without Telerik involvement. As @malsabi suspected, this is indeed related to when the StrokeThickness property is set to 0.

The reason it initially seemed to be related to Telerik is because we have implicit styles to standardize the styling. when you add our package, the Entry's default style has StrokeThickness set to 0 by default, while the Microsoft File > New > Maui project has this value set to 1 by default.

I am still waiting on the engineering team to verify my findings for the Telerik Feedback Portal item. [edit] Removed code snippet that is no longer relevant, added note.

[cmpalmer66]

I may be seeing a similar (related?) issue with the widths of the CheckBox controls in WinUI. They are stuck at about a couple of cm wide (with blank space to the right of the checkbox) and setting their WidthRequest or changing their parent container doesn't seem to affect how they render. I had to put the checkbox in grid cell with a ColumnDefinition with a width of "35" to clip the extra space off the Checkbox.

Later tonight, I'm going to try to isolate this problem. It may be related to this issue, or it may be a separate issue. The reason I suspected they might be related is that the extent of the CheckBox control is about the same width that the Entry control is locked to, and, like the Entry, it doesn't respect WidthRequests etc.

[malsabi]

@PureWeen Can you please reopen this issue and fix it as soon as possible

[LanceMcCarthy]

Hi folks, after digging into the Live Visual Tree Explorer, I have some more evidence on what is responsible. Please see my 1 minute explanation with evidence at runtime https://www.screencast.com/t/v7JTtug3U

First, @cmpalmer66 the reason using HorizontalOption=Stretch has no effect is because it is already still using Strech. see my video for an explanation.

Now, what is responsible for the inner area? It depends on what part of the control we need to look at next. I highly suspect Border to be responsible, but need more time to dig into the Handler (which is of type MauiPasswordBox on Windows)

[sbloomztf]

Same issue encountered today, and yes I am using telerik controls, but this is a new bug introduced in 8.0.90. It was okay with 8.0.82.

[LanceMcCarthy]

@sbloomztf As a temporary workaround, you can use RadEntry instead of Entry, if you have to use 8.0.90. See Didi's response here https://feedback.telerik.com/maui/1665106-version-7-1-0-and-maui-version-8-0-90-break-sizing-of-winui-entry-controls

You can follow that item to see what our findings will be, too.

[malsabi]

Why is this still considered close? Should I make a new issue? I can link a new repo without Telerik showing its still bugged when using Custom Entry with Border Thickness being set to 0. Please let me know @PureWeen

[drasticactions]

@LanceMcCarthy Could you please create an example repo of this happening with the standalone controls? I'm unsure of what exactly you're setting or wrapping the views around, but as you said you can get it to happen outside of Telerik then this should be open until shown otherwise.

[LanceMcCarthy]

@malsabi Can you please share the demo project that reproduces the issue with @drasticactions ?

I do not have something handy, and what you just described sounds like it's the underlying problem.

[malsabi]

@LanceMcCarthy Sure here is the result without using Telerik.

I have added implicit styles in the Platforms/Windows/app.xaml for the TextBox.

Repo: https://github.com/malsabi/EntryIssue

Result:

[drasticactions]

Yeah, there's an issue here. But it's... weird. As far as I can tell, the act of setting TextBox.BorderThickness period causes the Textbox to truncate. Setting it to 0, 1, 50, doesn't matter. It will always truncate. If you remove the style, it expands within the container.

With the Live Visual Tree, you can inspect the inner WinUI Elements. The Textbox itself is full width, but the elements inside it are truncated. If you set a Width on the Border, it does expand to match the specific width and the other elements in it match. But only with Border. Any other element inside it won't force it to expand.

[malsabi]

@drasticactions Yes, I noticed the same thing. When setting BorderThickness to 0 in the EntryHandler.cs class, it doesn't have any effect unless a style is applied, which then causes the same issue. This behavior started with version 8.0.90.

Note: I would expect setting BorderThickness to 0 in the EntryHandler to behave the same way as setting it through a style. I'm not sure why the border thickness only changes when a style is added.

[drasticactions]

I think I figured it out

https://github.com/dotnet/maui/pull/24485

This PR regressed it. I think it's forcing the delete button to truncate because it's setting the width to Auto in the inner column, and the setting of the Border width happens to trigger the inner logic within the control to resize it.

If this code is reverted, all is right again and it's full width.

This only would be seen if you set TextBox.BorderThickness in your WinUI Themes, but I think this logic here isn't correct since it would break the basic construction of the control. IMO the safe thing to do would be to revert it to the original implementation and rethink this. @PureWeen

[LanceMcCarthy]

Nice find @drasticactions!

This also explains why it initially appeared to be a Telerik issue (because we do have native styles to adhere to cross platform consistency).