Microsoft-ui-xaml: Discussion: Should light dismiss eat the first click, or let the click fall-through?

[alanlai-ms]

I am a OneNote developer, and I am currently working on bringing over the CommandBarFlyout into OneNote. The idea is to bring the Floatie command bar that exist in the Win32 version of OneNote into UWP version.

While implementing this, some questions arises around the light dismiss behavior that the Xaml framework implemented and defined (defined as https://github.com/microsoft/microsoft-ui-xaml/issues/685#issuecomment-493587598) vs what is traditionally the case for Win32 apps. (e.g. Onenote Win32, Window Explorer, Word Win32)

To be clear: As defined, the Xaml frame work "eats" the first click for each light dismiss surfaces such as flyout.
But traditionally in Win32, any clicks outside of the light dismiss panel falls through automatically into the UIelement you click on.

specifically in my case,

When I have the CommandBar and its submenu (flyout) opened like the picture above.
At this state, say you didn't see what you want from our CommandBarFlyout and you actually wants to click on a button on the ribbon...

In case 1, where OneNote is following Platform's light dismiss behavior, it takes 3 clicks.
1st click dismiss the sub menu flyout.
2nd click dismiss the CommandBarFlyout
3rd click actually clicks on a button

In case 2, where OneNote is following win 32 behavior and also how Windows Explorer is working...
The 1st click on the button would do all of dismissing the flyout, dismiss the CommandBar Flyout, and click the actual button.

I believe case 2 is preferred?
But the UWP platform behaves as case 1 right now.

Some prior context within the comments within these two threads for the record.
https://github.com/microsoft/microsoft-ui-xaml/issues/685#issuecomment-493587598
https://github.com/microsoft/microsoft-ui-xaml/issues/820

[shaheedmalik]

Make it like Case 2, IMO. That's how Win32 apps do it. That's how new Edge does it.

Less Clicks = Better.

[bschoepke]

For pen I would say eat the input, otherwise it would draw on the page and you'd end up with a bunch of small marks to erase. Not sure what the guidance is for other inputs.

[shaheedmalik]

How Win32 does it now, it seems it only clicks through only for menus and buttons.

[dpierangeli]

I think that the new model is better, the user could click anywhere to close the light dismiss surfaces and then select the button.

Less click is not ever better, if i click on the wrong button when dismissing the surface or if i must 'search' for the correct spot to close.

Yet case 1 is not good, the click should close 'all' the light dismiss surfaces (that's like a specific case that should be handled by the CommandBar + Flyout).

[Poopooracoocoo]

Another part for discussion: should the ribbon and other elements be shown as disabled if it eats the input?

[YuliKl]

Another part for discussion: should the ribbon and other elements be shown as disabled if it eats the input?

Great point, @Poopooracoocoo. I would further subdivide this question into two:

1. Should there be a visual indication in the app UI that it's covered up by a light-dismiss layer (if that layer eats clicks)?
2. What should that visual indication look like?
   a. controls underneath are in their disabled states?
   b. the light-dismiss layer includes a smoke layer similar to a dialogs? (although usually smoke means the UI on top is modal)
   c. something else...?

[YuliKl]

Yet case 1 is not good, the click should close 'all' the light dismiss surfaces (that's like a specific case that should be handled by the CommandBar + Flyout).

Completely agreed with @dpierangeli. Dismissing cascading menu items closes everything with a single click. If CommandBarFlyout isn't doing that for its AppBarButtons' flyouts, that feels like a bug in the control.

[YuliKl]

@shaheedmalik, thank you for checking! For my education, in which situation does Win32 appear to eat the click?

Perhaps Xaml's approach to light-dismiss needs to be more nuanced than the current behavior. We eat the click no matter what kind of light dismiss UI is currently up.

[shaheedmalik]

I think that the new model is better, the user could click anywhere to close the light dismiss surfaces and then select the button.

Less click is not ever better, if i click on the wrong button when dismissing the surface or if i must 'search' for the correct spot to close.

Yet case 1 is not good, the click should close 'all' the light dismiss surfaces (that's like a specific case that should be handled by the CommandBar + Flyout).

Clicking anywhere but a menu or a button would clear the menu like how It's done in Word and old OneNote currently.

In fact this is how context menus currently operate in Outlook Mail UWP.

Try this for example:

Select some text in Outlook Mail, right click on it. (Copy is shown as a context menu)
If I click a hyperlink, the click will activate the hyperlink.

[shaheedmalik]

@shaheedmalik, thank you for checking! For my education, in which situation does Win32 appear to eat the click?

Perhaps Xaml's approach to light-dismiss needs to be more nuanced than the current behavior. We eat the click no matter what kind of light dismiss UI is currently up.

If I am in new Edge for example and click on anything besides a menu or button, the click is ate.
If I have a context menu up and I go to select text, the menu will be canceled and the text will select.
To cancel the click one has to click on white space.

I just checked in Photoshop, If I am drawing and I bring up a context menu, and I go to draw again, the menu will cancel and the drawing will occur.

[YuliKl]

@alanlai-ms, I'm not seeing this behavior:

In case 1, where OneNote is following Platform's light dismiss behavior, it takes 3 clicks.
1st click dismiss the sub menu flyout.
2nd click dismiss the CommandBarFlyout
3rd click actually clicks on a button

In my simplistic sample app

        <muxcontrols:CommandBarFlyout Placement="Right" x:Name="CommandBarFlyout1">
            <AppBarButton x:Name="ShareButton1" Label="Share" Icon="Share" Click="OnElementClicked" />
            <AppBarButton x:Name="SaveButton1" Label="Save" Icon="Save" Click="OnElementClicked" />
            <AppBarButton x:Name="DeleteButton1" Label="Delete" Icon="Delete" Click="OnElementClicked" />
            <muxcontrols:CommandBarFlyout.SecondaryCommands>
                <AppBarButton x:Name="ResizeButton1" Label="Resize">
                    <AppBarButton.Flyout>
                        <MenuFlyout>
                            <MenuFlyoutItem Text="Hello"/>
                            <MenuFlyoutItem Text="Goodbye"/>
                        </MenuFlyout>
                    </AppBarButton.Flyout>
                </AppBarButton>
                <AppBarButton x:Name="MoveButton1" Label="Move" Click="OnElementClicked" />
            </muxcontrols:CommandBarFlyout.SecondaryCommands>
        </muxcontrols:CommandBarFlyout>

Hovering over ResizeButton1 opens the Hello/Goodbye submenu. Clicking anywhere on the page once closes both the CommandBarFlyout and the MenuFlyout.

Is it possible that your needing two clicks to dismiss all the open flyouts is a result of custom OneNote code?

[alanlai-ms]

@YuliKl

It is possible it is due to we are using AppBarElementContainer that allows users of that to host anything we want.
In this case, we are hosting a button that when clicked, would open a popup.
The popup it self is not a direct children of the secondary bar, but a sibling.

The bug here might be the platform provide no way to handle this case when apps opt to use AppBarElementContainer?

[Poopooracoocoo]

interestingly, AutoSuggestBox box acts like #2, not #1.

[Poopooracoocoo]

@shaheedmalik

If I am in new Edge for example and click on anything besides a menu or button, the click is ate.

I can't reproduce that. When the menu is shown and I click on a link, it navigates to that link. The problem is that the cursor nor link do not change to reflect that. That's an issue on Google and Microsoft Edge's side however.

[shaheedmalik]

@shaheedmalik

If I am in new Edge for example and click on anything besides a menu or button, the click is ate.

I can't reproduce that. When the menu is shown and I click on a link, it navigates to that link. The problem is that the cursor nor link do not change to reflect that. That's an issue on Google and Microsoft Edge's side however.

That's what I said.

If you have a menu up and you click a button or menu, it will work.. If you click in whitespace then it is ate.

[YuliKl]

@alanlai-ms, thank you, this is what I was missing.

It is possible it is due to we are using AppBarElementContainer that allows users of that to host anything we want.

When I change my sample code to use AppBarElementContainer it indeed takes me two clicks to close both flyouts.

<muxcontrols:CommandBarFlyout Placement="Right" x:Name="CommandBarFlyout1">
    <AppBarButton x:Name="ShareButton1" Label="Share" Icon="Share" Click="OnElementClicked" />
    <AppBarButton x:Name="SaveButton1" Label="Save" Icon="Save" Click="OnElementClicked" />
    <AppBarButton x:Name="DeleteButton1" Label="Delete" Icon="Delete" Click="OnElementClicked" />
    <muxcontrols:CommandBarFlyout.SecondaryCommands>
        <AppBarElementContainer>
            <SplitButton>
                Paste
                <SplitButton.Flyout>
                    <MenuFlyout>
                        <MenuFlyoutItem Text="Hello"/>
                        <MenuFlyoutItem Text="Goodbye"/>
                    </MenuFlyout>
                </SplitButton.Flyout>
            </SplitButton>
        </AppBarElementContainer>
    </muxcontrols:CommandBarFlyout.SecondaryCommands>
</muxcontrols:CommandBarFlyout>

This is nested (not cascading) Xaml flyout behavior.

You may be able to work around this using OverlayInputPassThroughElement on your ContainerPanel.

[YuliKl]

To get back to the original question posed in the title of this issue. It seems that Win32 has somewhat inconsistent behavior. Does anyone feel strongly that Xaml's default of swallowing the first light-dismiss click is incorrect and needs to be changed?

@mdtauk, @mrlacey, @felix-dev, @sonnemaf, @mobiletonster - do you have any thoughts on this question?

[mdtauk]

I am not sure tbh. I am willing to follow the thoughts of Windows and Office engineers, who would have done studies on this kind of thing.

If I understand the issue properly. The OneNote developer wants Light Dismiss to work as is when clicking or tapping on a surface without a hit target, but if tapping on a valid hit target, with a light dismiss flyout open, it will activate the tapped item, whilst dismissing the flyout.

It would be interesting to hear the thoughts of those who built the WinRT interaction models, if they have any telemetry of where users are tapping to dismiss flyouts. Do they avoid obvious things like buttons in order to dismiss - if so changing the behaviour will not have much downside.

[shaheedmalik]

I think it needs to be changed.

[dpierangeli]

I think that the default is correct:

• now the users are 'Mobile Users' first and the light dismiss is the default on a lot of those experiences. (and on websites too)

• the light dismiss is more secure, the user can click anywhere without conseguences

• the user should not 'search' for a whitespace to dismiss the surface

But maybe the system can add an opacity/smoke/cursor change/something to show the user that the click wil be swallowed, with that the developer should be able to turn off the 'swallow' (and that should be easier to do - maybe a global set/property ? - ).

(here in github if you click on '...' at the left of a message a command popup is opened, in that case all clicks on the page are 'swallowed', but the user knows that - the hover states are not applied..)

[Felix-Dev]

To be clear: As defined, the Xaml frame work "eats" the first click for each light dismiss surfaces such as flyout.

This is particulary annoying in the following example:

As you can (hopefully) see, I always need to click twice before a flyout opens. With no visual indication such as a smoke overlay (as used by controls such a ColorPicker or other Dialog controls) I found, and still find, this behavior to be quite irritating. I clearly want to open Windows Power-flyout, but coming from another flyout, I have to click twice to get to it which is quite annoying.

Conclusion: In the case above, I prefer changing the current behavior to "with a light dismiss flyout open, [a click] will activate the tapped item, whilst dismissing the flyout"

If, however, the current behavior is to be kept (swallowing the first light-dismiss click), I'd definitely advocate to add some sort of visual indication of this behavior for the user.

[YuliKl]

Thank you everyone for your thoughts! Based on everything I read here, I opened new issue #917 to update Xaml's light dismiss behavior. Please edit that proposal to make it more detailed and accurate.

[YuliKl]

Closing this discussion issue and moving further design conversations to #917.

[Poopooracoocoo]

holy smokes. how has OneNote UWP changed so little in almost two years?

@alanlai-ms Will OneNote switch to WinUI and will OneNote contribute its ribbon?