Reopen #11785: FlyoutPage.IsPresented=false throws InvalidOperationException: 'Can't change IsPresented when setting Default' (default or any other value that can have a non collapsable Flyout behavior)

[axa88]

Description

There has long been issue with the Flyout.IsPresented property as reported before in bug #11785

The original bug report is valid, but as de facto protocol, upon a new version of .NET, issues will be closed with a "s/try-latest-version" label for no apparent reason. So I will attempt to help clarify the issue so it might be fixed this time around.

As we are aware the purpose of the IsPresented property is to both programmatically set and get the presentation of the Flyout.
The trouble is when attempting to set IsPresented, if the window is in a 'split' behavior having a non collapsible Flyout page, you will not be allowed to set the property to false. This may well make sense as this given mode demands the Flyout always be viewable.
But attempting to hide it is rejected with an InvalidOperationException thrown.
And this is all a larger problem because (besides upon page page initialization) the value of IsPresented does not work in and of itself, it is not settable, and wont always reflect the current presentation state of the Flyout. Then consequentially the IsPresentedChanged event may not trigger. Just as reported in bug #15767, clicking the hamburger menu button to close and open the Flyout when FlyoutLayoutBehavior = Popover will not set the IsPresented property.

Beyond this malfunction, the trouble with the current design of the API is that the actual current behavior of the window is not available to the programmer, so they wont even be able to try and avoid the above issue.
The property FlyoutLayoutBehavior should report the actual current behavior, but it does not. The actual behavior depends on both the current FlyoutLayoutBehavior value AND the current width of the window.
So unless there is some a way to calculate this, a programmer cant even know what the actual behavior is and try to avoid the issue.

For example on WinUI, when the window is wide, AND the FlyoutLayoutBehavior is either Default , SplitOnPortrait or SplitOnLandscape , then the behavior is 'split' (non collapsible Flyout and Detail). But with these same FlyoutLayoutBehavior values, if the window is narrow, then the behavior is 'popover' (collapsible Flyout page). Therefor a programmer can't know what the behavior is at any particular time, and attempt to avoid setting IsPresented property false when it will cause the issues described above.

So in summary these are the issues:

• There is no purpose to throw an exception under these conditions, especially if the program cant even know when or how to avoid triggering it because conditions to trigger an exception charge without notice, such as when a user charges window size.
• IsPresented doesnt work, it isn't always settable depending on window size and may not accurately reflect the state of the Flyout Page.
• subsequently IsPresentedChanged may not not trigger when the Flyout presentation changes due to the undefined conditions mentioned previously.
• Also this is a piss poor API design:

At the very least the API should have the FlyoutLayoutBehavior property always report the actual Flyout behavior. Not what the suggested behavior might be, depending on window width. And arguably there also should be a new event "FlyoutLayoutBehaviorChanged" added to report a user may have resized the window and caused a change of the FlyoutLayoutBehavior value.
Furthermore, the FlyoutLayoutBehavior.Default value needs to be documented or perhaps removed all together. At the very least it can be a valid setting value, but should never be the getting value. There is just currently no good way to know what the behavior of a "Default" is going to be, especially if its based on a variable sized window with no specifications, across multiple platforms.

Hopefully this enough detail for the issue to not be simply dismissed after .NET 9 comes out and the issue hadn't been addressed

Steps to Reproduce

See bug 11785
It reports being able to use the very sample programming to reproduce

Link to public reproduction project repository

https://github.com/dotnet/maui-samples/tree/main/6.0/Navigation/FlyoutPageSample

Version with bug

8.0.3

update: Maui.Controls 8.0.61

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

8.0.3/8.0.100

Did you find any workaround?

In WinUI avoid setting IsPresented = false or set the FlyoutLayoutBehavior to Popup before setting the property false

Of course this likely fails to provide the functionality a user wishes to have, so there's no point.

One could attempt to subscribe to the Flyout.Focused and Flyout.Unfocused events, and adjust the IsPresented property value manually, which in turn will trigger IsPresentedChanged

Though this is a poor fix as there are various reasons the Flyout might lose focus that doesn't include the Flyout no longer being presented (IsPresented = false), such as the window is minimized, or a Popup takes focus away without changing the Flyout presentation state.

Better the issue just gets a proper fix

Relevant log output

No response

[axa88]

Note the template question:
Is this a regression from previous behavior?
There is no appropriate answer to this question, as noted not something new.
It never worked correctly, but that is not a valid option.

[axa88]

Experimenting with Window Width i was unable to guess when a Flyover Page might start acting with one type of behavior and the other as there seems to be some sort of Hysteresis employed toggling its own functionality from and to collapsible and non collapsible Flyout behaviors. Meaning depending on which the current behavior is, and if you are either expanding or collapsing the window, it will toggle into the other behavior at different widths.
I dont have the time to reverse engineer this and create an algorithm to try and determine the correct points across all variables.

[axa88]

Also the hamburger menu button is broken in its triggering states.

On WinUI, the function is at least not intuitive, if not broken.
When the Flyout is collapsed, the button will only trigger the Flyout to open upon click RELEASE.
When the Flyout is presented, the button will trigger the Flyout to collapse upon click PRESS, but then the subsequent click RELEASE will just reopen the Flyout to presented. You need to slide your pointer off of the hamburger button before releasing in order to keep the Flyout open.
This behavior is surely unintended.

[axa88]

Also on WinUI, when setting a flyout layout behavior and window size that results in a a popover type behavior,
using the hamburger menu button, the first time the Flyout is Opened as well as the first time the Flyout is closed, neither the Flyouts' Focused nor Unfocused events will trigger. Yet, continuing to press the hamburger menu button to Open the Flyout, the Flyout Focused event will trigger, and upon closing the Flyout, Flyout Unfocused event will trigger, with each subsequent hamburger button request.

[axa88]

@samhouts why tag this issue area Shell.

It has nothing to do with Shell.

[mnxamdev]

This is also an issue with .Net 8 on iPads landscape as mentioned in the original issue which was opened 12/2022. Is there going to be some sort of escalation to get this fixed sooner than 1 year?

#11785 (comment)

[imuller]

Same here, is there no property to check if we can set this property?

[kevinxufei]

Verified this issue with Visual Studio 17.10.0 Preview 4(8.0.20&8.0.0-rc.2.9530),Can repro this issue.

[FlavioGoncalves-Cayas]

This is also an issue with .Net 8 on iPads landscape as mentioned in the original issue which was opened 12/2022. Is there going to be some sort of escalation to get this fixed sooner than 1 year?

#11785 (comment)

I don't think so.

[axa88]

is there no property to check if we can set this property?

no. arguably there should be.
Rational. In a xplatform environment there are many rules and expecting a user to know which rules apply in a given situation is unreasonable. A property like CanToggleIsPresented might make sense

[axa88]

And quietly moved to the backlog.... Lets hope the next move isn't another close out

[lukasrut]

Is any progress with this issue???

[axa88]

This just keeps biting me in the ass...