-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[regression/8.0.0-preview.3.8149] Header in flyout menu makes first menu item not clickable on IOS #17965
Comments
Is this something that worked in 7.0 and is failing since updating to 8.0? Thanks! |
Hi @michaelonz. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time. |
Hi - it worked in 7 - it’s a regression. |
Can confirm that this is an issue in .Net 8 and not .Net 7. Will update if I find any causes/workarounds. |
This is an issue in .net 8 rc2 and rc1 |
I just tested every .Net 8 preview until I found one with a different behavior... In 8.0.0-preview.1.7762 and 8.0.0-preview.2.7871 there was a spacing issue between the header and the flyout menu items (ref #11679). There was a large gap between the header and the items but the items were all able to be interacted with. That visual spacing issue was fixed by PureWeen in #12480 and merged into 8.0.0-preview.3.8149. Since 8.0.0-preview.3.8149 this issue has existed where the items are placed properly but the area that we can tap/interact with still seems to be blocked. I am not sure if related to #12480 but I think it's likely. Furthermore, It's not always the first item that can't be tapped, it can be the first and second based on device screen size and item size. |
Thanks @jcsnider for narrowing it down - will this be resolved in the next release? |
I'm not part of the team myself, and although I hope this is fixed in the next release I am proceeding as if it won't be and looking to work around it. Provided that this has been an issue for many months and not more popular I feel like it's due to something we are doing differently from the majority of users. If I find any more info or workarounds I'll continue to update here. I'm also going to tag #17432 because I think these issues are related or the same. Not sure if it helps but my Flyout header is very similar to yours with a grid that has a static height request with a background image? and a stack layout inside...
|
Hi @jcsnider , the only work around I’ve found was to have no menu items and then create the menu items using buttons and images in the header - so it looks the same but there is effectively no menu items. This however is a terrible work around but if anyone is desperate to work around it then it does work - but means menus are unusable with a header right now in Maui 8 |
@michaelonz -- I love it.. so simplistic and elegant. No idea why I didn't think of that. I'm gonna mess with this for another hour or so and then I'll fallback to that. Thanks. Edit: I did find that if you give your element inside the header a Margin property value it will ruin the rendering of your header but the menu items will display in the correct spots and work -_- |
So another option.. is to add a margin property to the top level view inside the header (in our case the grid) and also set a minimumheightrequest property that is a bit bigger than the heightrequest property on ios. I added the following in my AppShell constructor.
The above makes my flyout work nearly perfectly. Afterwards the only issue the white horizontal bar above my header.. maybe a ios safe area thing? Either way I can live with it until a proper fix is released. Tested and working on an iPhone 8 simulator and a iPhone 14 Pro Max (very different sizes). |
@jcsnider - I will give this a try tomorrow also and report back my findings …..:) |
HI @jcsnider - Good work - that has resolved my issue also so it appears the issue is related to either one or both of the properties you have provided. Maui Team still need to resolve it as its a tough one to narrow down - but that gets us past it for now (although i would like to try it on ipad etc etc) |
You're awesome!! Thank you so much for doing this research. We'll get started on the fix and plan to have it ready by GA or SR1, depending on the risk of the change. |
Probably here in the comments, but looking closer and making item heights all different sizes I see that the first item is partially clickable if it is larger that the safe area height. |
I'm experiencing this issue also: iOS Specifically the first menu item isn't clickable. This is on an iPhone 13 Mini simulator specifically. |
The Flyout Header height was being defined as `ArrangedHeaderViewHeightWithNoMargin` + `HeaderTopMargin`, but the `HeaderView.MeasuredHeight` (value on which `ArrangedHeaderViewHeightWithNoMargin` is based on) does include the margin so we were accounting for it twice and making the header go over the items below it, making them not clickable. When there is no margin, `HeaderTopMargin` represents the safe area and it should not be accounted for either. Fixes #17965
The Flyout Header height was being defined as `ArrangedHeaderViewHeightWithNoMargin` + `HeaderTopMargin`, but the `HeaderView.MeasuredHeight` (value on which `ArrangedHeaderViewHeightWithNoMargin` is based on) does include the margin so we were accounting for it twice and making the header go over the items below it, making them not clickable. When there is no margin, `HeaderTopMargin` represents the safe area and it should not be accounted for either. Fixes #17965
I just confirmed this; If you add a Shell.FlyoutHeader to the flyout menu then the first flyoutmenu item on IOS is not clickable (android works fine). I didn't know this was an issue until I found this BUG report. Please fix. |
Yeah I just tested this, this is an issue for me developer friend. |
This also occurs with FlyoutContent, the top 48 dp of FlyoutContent is not clickable if you have a FlyoutHeader |
The Flyout Header height was being defined as `ArrangedHeaderViewHeightWithNoMargin` + `HeaderTopMargin`, but the `HeaderView.MeasuredHeight` (value on which `ArrangedHeaderViewHeightWithNoMargin` is based on) does include the margin so we were accounting for it twice and making the header go over the items below it, making them not clickable. When there is no margin, `HeaderTopMargin` represents the safe area and it should not be accounted for either. Fixes #17965
The Flyout Header height was being defined as `ArrangedHeaderViewHeightWithNoMargin` + `HeaderTopMargin`, but the `HeaderView.MeasuredHeight` (value on which `ArrangedHeaderViewHeightWithNoMargin` is based on) does include the margin so we were accounting for it twice and making the header go over the items below it, making them not clickable. When there is no margin, `HeaderTopMargin` represents the safe area and it should not be accounted for either. Fixes #17965
The Flyout Header height was being defined as `ArrangedHeaderViewHeightWithNoMargin` + `HeaderTopMargin`, but the `HeaderView.MeasuredHeight` (value on which `ArrangedHeaderViewHeightWithNoMargin` is based on) does include the margin so we were accounting for it twice and making the header go over the items below it, making them not clickable. When there is no margin, `HeaderTopMargin` represents the safe area and it should not be accounted for either. Fixes #17965
The Flyout Header height was being defined as `ArrangedHeaderViewHeightWithNoMargin` + `HeaderTopMargin`, but the `HeaderView.MeasuredHeight` (value on which `ArrangedHeaderViewHeightWithNoMargin` is based on) does include the margin so we were accounting for it twice and making the header go over the items below it, making them not clickable. When there is no margin, `HeaderTopMargin` represents the safe area and it should not be accounted for either. Fixes #17965
The Flyout Header height was being defined as `ArrangedHeaderViewHeightWithNoMargin` + `HeaderTopMargin`, but the `HeaderView.MeasuredHeight` (value on which `ArrangedHeaderViewHeightWithNoMargin` is based on) does include the margin so we were accounting for it twice and making the header go over the items below it, making them not clickable. When there is no margin, `HeaderTopMargin` represents the safe area and it should not be accounted for either. Fixes #17965
The Flyout Header height was being defined as `ArrangedHeaderViewHeightWithNoMargin` + `HeaderTopMargin`, but the `HeaderView.MeasuredHeight` (value on which `ArrangedHeaderViewHeightWithNoMargin` is based on) does include the margin so we were accounting for it twice and making the header go over the items below it, making them not clickable. When there is no margin, `HeaderTopMargin` represents the safe area and it should not be accounted for either. Fixes #17965
@emaf it looks like you have done a lot of commits to resolve this - can you give any indication when this might ship? I want to know if i need to start programming work arounds of if the next release will have a resolution and rough ball park release date so we can plan internally (I know you cant give a fixed date but an indication of a target would be appreciated) |
The Flyout Header height was being defined as `ArrangedHeaderViewHeightWithNoMargin` + `HeaderTopMargin`, but the `HeaderView.MeasuredHeight` (value on which `ArrangedHeaderViewHeightWithNoMargin` is based on) does include the margin so we were accounting for it twice and making the header go over the items below it, making them not clickable. When there is no margin, `HeaderTopMargin` represents the safe area and it should not be accounted for either. Fixes #17965
@michaelonz if everything goes alright, the plan is to ship those changes in .NET 8 SR2. We need to land those changes in main first, and then see how they go before being certain about it. Once the changes landed in main, you can use nightly builds to give those a try. |
* [iOS] Fix Flyout Header breaking clicking over items The Flyout Header height was being defined as `ArrangedHeaderViewHeightWithNoMargin` + `HeaderTopMargin`, but the `HeaderView.MeasuredHeight` (value on which `ArrangedHeaderViewHeightWithNoMargin` is based on) does include the margin so we were accounting for it twice and making the header go over the items below it, making them not clickable. When there is no margin, `HeaderTopMargin` represents the safe area and it should not be accounted for either. Fixes #17965 * Rename confusing properties Rename `ArrangedHeaderViewHeightWithNoMargin` and `MeasuredHeaderViewHeightWithNoMargin`, to `ArrangedHeaderViewHeightWithMargin` and `MeasuredHeaderViewHeightWithMargin`, since both include the top margin value: https://github.com/dotnet/maui/blob/main/src/Core/src/Layouts/LayoutExtensions.cs#L27. * Fix tests * Fix safe area margin bottom value * Fix margins * Polish flyout header and content offsets * Remove extra space * Simplify content layout * Small code cleanup * Fix condition * Simplify test * More tests * Test fix * Add ArrangedHeaderViewHeightWithOutMargin * Broken * Fix scrollview inset * Fix all tests * Fix scroll view content inset and expand tests * Fix new test cases for Android * Skip FlyoutHeaderContentAndFooterAllMeasureCorrectly for Android since there is a bug that makes tests fail * Enable more tests for iOS * Honor IgnoreSafeArea * Add missing null check * Fix CollectionView support * Add check by ItemsView for CV * Add tests scrolling using different content control types * Log more info on new tests * Use requested value for assertion * Consider epsilon for scrolled position * Better test logging * Fix spacing * Another indenting issue * Fix namespaces
This isn't fixed in the latest release. Still can't click when having an header... |
Can you try the nightly builds? I see this was merged 2 weeks ago, but due to other reasons the sr1 that shipped a few days ago was actually supposed to go out a few weeks ago. So effectively this was merged after the release branch was created. This should be in the next release. |
When will this fix be actually included in a non preview release, I can qa test it out there once it's out. I can't install preview visual studio at the moment.
PaulAstramowicz.com
…________________________________
From: Matthew Leibowitz ***@***.***>
Sent: Saturday, January 20, 2024 12:03:34 PM
To: dotnet/maui ***@***.***>
Cc: Paul Astro ***@***.***>; Comment ***@***.***>
Subject: Re: [dotnet/maui] [regression/8.0.0-preview.3.8149] Header in flyout menu makes first menu item not clickable on IOS (Issue #17965)
Can you try the nightly builds? I see this was merged 2 weeks ago, but due to other reasons the sr1 that shipped a few days ago was actually supposed to go out a few weeks ago.
So effectively this was merged after the release branch was created. This should be in the next release.
—
Reply to this email directly, view it on GitHub<#17965 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AK2EVSQNLUAGABE2EH44MVDYPOQANAVCNFSM6AAAAAA546PQ2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGA3DMMBTGM>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Description
When you have a shell flyout menu and have no Shell.FlyoutHeader then all the menu items work correctly on both ios and android.
If you add a Shell.FlyoutHeader to the flyout menu then the first flyoutmenu item on IOS is not clickable (android works fine).
NOTE: If you remove the Shell.FlyoutHeader then it works fine.
In the example shell.xaml below the first flyoutmenu item named 'Clicking Me Doesnt Work' wont work on IOS.
Steps to Reproduce
Link to public reproduction project repository
No response
Version with bug
8.0.0-preview.3.8149
Is this a regression from previous behavior?
Yes, this used to work in .NET MAUI
Last version that worked well
8.0.0-preview.2.7871
Affected platforms
iOS
Affected platform versions
16.6
Did you find any workaround?
#17965 (comment)
Relevant log output
No response
The text was updated successfully, but these errors were encountered: