Microsoft.Maui.Controls 8.0.90 (Latest stable) Ruins Entry Controls #24783
Comments
|
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:
Closed similar issues:
|
|
I can see
That's a bit confusing. |
|
Also a screenshot comparing the new and the old behavior would be very helpful here. |
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: |
|
@MartyIX 8.0.90 is not yet available in the issue template |
I see. The issue van be post-editted then. |
PureWeen
added
the
potential-regression
|
Can confirm this on our App. SR9 cannot be used at the moment.
|
|
Interestingly, I don't observe this behavior in my app. |
PureWeen
added
the
s/needs-repro
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. |
dotnet-policy-service
bot
added
s/needs-attention
|
ok, this one took me some time. really strange... |
|
@baaaaif , the problem does happen again if I install Telerik NuGet and put .UseTelerik() in MauiProgram.cs |
|
@TelerikMauiTeam sorry for pinging, but might be in your interest |
ninachen03
added
s/triaged
|
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. |
Yes, they are not on Nuget, I believe you need to download them from Telerik's website |
|
Telerik have their own NuGet source |
dotnet-policy-service
bot
removed
the
s/try-latest-version
|
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. |
|
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? |
PureWeen
removed
s/needs-attention
|
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. |
|
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 |
|
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 |
|
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 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. |
|
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. |
|
@PureWeen Can you please reopen this issue and fix it as soon as possible |
|
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 |
|
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. |
|
@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. |
|
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 |
|
@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. |
|
@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. |
|
@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: |
|
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. |
|
@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. |
|
I think I figured it out 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 |
|
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). |
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
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
The text was updated successfully, but these errors were encountered: