When Command Bar is opened, it behaves as a modal dialog and anything under it is not clickable.

[alanlai-ms]

Describe the bug

See sample app at \scratch2\scratch\rnichols\CommandBarFlyout.zip that repros the same issue trivially with WebView. WebView doesn’t react at all to input while the flyout is up – including mouse hover.

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'

Expected behavior

Screenshots

Version Info

NuGet package version:

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)
Anniversary Update (14393)

Device form factor	Saw the problem?
Desktop
Mobile
Xbox
Surface Hub
IoT

Additional context

[YuliKl]

@alanlai-ms - the behavior you describe is by design to help constrain the area of user input (open CommandBar also traps keyboard focus). We generally expect CommandBar to be closed the majority of the time, which eliminates this input-blocking behavior. Do you have a specific scenario that's making CommandBar's default behavior painful?

[alanlai-ms]

@YuliKl , when people right click on an app, Let say OneNote and the Context Menu is opened.

At this state, user found out that the command they want is not actually in the Context Menu but in the Ribbon.

They click "once" on the actual button on the ribbon and fully expect it to trigger the action.
It doesn't.

Now user requires 2 clicks, 1st to dismiss CommandBarflyout 2nd click finally triggers the action from ribbon.

[alanlai-ms]

I think generally when context menu is opened, user expect clicking on a different area, and input would fall thru.

[YuliKl]

Light dismiss swallows the first click. Meaning, when a light dismiss menu or flyout is open, clicking outside the menu/flyout dismisses it but the click does not pass through to the underlying UI. Users need one click for the light dismiss and a second to activate the UI. The purpose of this mechanism is to reduce accidental activations and ensure that light dismiss clicks feel safe to users. There's more discussion about light dismiss in our docs.

For scenarios where single-click-to-dismiss-and-activate are critical, you can use the OverlayInputPassThroughElement property. Although this property is on FlyoutBase and I believe isn't available for CommandBar's overflow menu.

[alanlai-ms]

Maybe the CommandBarFlyout shouldn't be a light dismiss surface then if light dismiss surface is defined that way?

Reason

1. CommandBarFlyout, to a user is just a context menu, and in a context menu, say if you try in Window Explorer, when it is opened and you click somewhere else, that click registers as click

2. The concept of CommandBarFlyout isn't new, it has been around in Office Win 32 apps. In those apps, when the menu is opened and you click somewhere else, that click registers as click.

[dpierangeli]

CommandBarFlyout, to a user is just a context menu, and in a context menu, say if you try in Window Explorer, when it is opened and you click somewhere else, that click registers as click

Yes, and that's a pain.. to close a context menu i must always be careful to click on an 'empty space', otherwise i can trigger an action that i don't want.

I think that light dismiss is a correct and modern paradigm, also most of the user came from mobile&web experiences where it's the norm.

But if the developer wants to turn-off the feature it should be possibile.

[alanlai-ms]

What web experiences you are referring to where it's the norm?
On chrome, when I right click and then left click somewhere else, that 1st left click registers as click.

Going to ignore mobile (ios/Android) as we are using a mouse here and those are touch/pen devices.

'empty spaces' seems to be everywhere... e.g. look at the OneNote canvas, look at github webpage, look at your mail client canvas.

[dpierangeli]

What web experiences you are referring to where it's the norm?

Here in github when you open a 'command prompt' (eg: click the '...' in the top right of this message) and click to dismiss the click is 'swallowed'.

I see this pattern used a lot (ok, is not the 'norm') because i think that is simpler, it doesn't require a 'conscious' effort to close (the quantity of empty space is not the problem, the problem is that you must 'search' for it).

But if you want this feature turned-off the framework should let you, in this i'm with you.

And then let an A/B test decide what your users prefer ;) .

[YuliKl]

The problem with letting the developer decide whether a light-dismiss click gets swallowed or passes through is that the user doesn't know what to expect. We don't provide any affordances for the user to know whether their click is safe or they need to search for empty spaces in order to dismiss the menu. So to avoid user confusion, Xaml framework implemented the point of view that light dismiss layers swallow the first click.

@alanlai-ms - if you feel strongly that the Xaml light dismiss behavior needs to be changed, please open a new issue and include the justification.