Describe the bug
Popups such as MenuFlyout are constrained to the monitor's work area instead of being allowed to use the full monitor bounds. This prevents WinUI applications from intentionally displaying popups over areas such as the taskbar or notification area, even though the underlying code path--and nearly every other UI framework--supports this.
Why is this important?
Applications may want to create a native Windows experience in which a popup overlaps the taskbar or notification area. For example, a context menu or MenuFlyout associated with UI near the bottom edge of the screen. Other Windows UI frameworks do not appear to impose this restriction, limiting parity and unnecessarily restricting WinUI desktop applications.
Steps to reproduce the bug
- Create a WinUI application with a MenuFlyout or another popup-based control.
- Run the application on Windows with a visible taskbar or notification area.
- Open or position the popup near the edge of the monitor so that the desired placement would extend into the taskbar/work-area-excluded region.
- Observe that the popup is constrained to the monitor work area rather than being allowed to use the full monitor bounds.
Actual behavior
The popup placement logic uses the monitor work-area rectangle (monitorInfo.rcWork) when visualTree->ShouldConstrainPopupsToWorkArea() is enabled. As a result, the popup cannot be placed over the taskbar or notification area, even when the application is a desktop WinUI application and the developer intentionally wants that behavior.
Expected behavior
The application should be able to opt out of the work-area constraint and allow the popup to use the full monitor rectangle (monitorInfo.rcMonitor). The existing constrained behavior could remain the default for compatibility, with an app-level XAML override configurable at startup; alternatively, the constraint could just be removed.
Screenshots
No response
NuGet package version
2.3.9
Windows version
Windows Insider Build (xxxxx)
Additional context
Relevant implementation: DXamlCore.cpp#L3843-L3860
if (visualTree->ShouldConstrainPopupsToWorkArea())
{
availableMonitorRectScreenLogical = {
monitorInfo.rcWork.left / scale,
monitorInfo.rcWork.top / scale,
(monitorInfo.rcWork.right - monitorInfo.rcWork.left) / scale,
(monitorInfo.rcWork.bottom - monitorInfo.rcWork.top) / scale
};
}
else
{
availableMonitorRectScreenLogical = {
monitorInfo.rcMonitor.left / scale,
monitorInfo.rcMonitor.top / scale,
(monitorInfo.rcMonitor.right - monitorInfo.rcMonitor.left) / scale,
(monitorInfo.rcMonitor.bottom - monitorInfo.rcMonitor.top) / scale
};
}
The proposed fix is either to remove this constraint or expose a discoverable app-level override, such as a startup setting equivalent to Application.ConstrainPopupsToWorkArea = false, while preserving the current default behavior for existing applications.
Describe the bug
Popups such as
MenuFlyoutare constrained to the monitor's work area instead of being allowed to use the full monitor bounds. This prevents WinUI applications from intentionally displaying popups over areas such as the taskbar or notification area, even though the underlying code path--and nearly every other UI framework--supports this.Why is this important?
Applications may want to create a native Windows experience in which a popup overlaps the taskbar or notification area. For example, a context menu or
MenuFlyoutassociated with UI near the bottom edge of the screen. Other Windows UI frameworks do not appear to impose this restriction, limiting parity and unnecessarily restricting WinUI desktop applications.Steps to reproduce the bug
Actual behavior
The popup placement logic uses the monitor work-area rectangle (
monitorInfo.rcWork) whenvisualTree->ShouldConstrainPopupsToWorkArea()is enabled. As a result, the popup cannot be placed over the taskbar or notification area, even when the application is a desktop WinUI application and the developer intentionally wants that behavior.Expected behavior
The application should be able to opt out of the work-area constraint and allow the popup to use the full monitor rectangle (
monitorInfo.rcMonitor). The existing constrained behavior could remain the default for compatibility, with an app-level XAML override configurable at startup; alternatively, the constraint could just be removed.Screenshots
No response
NuGet package version
2.3.9
Windows version
Windows Insider Build (xxxxx)
Additional context
Relevant implementation: DXamlCore.cpp#L3843-L3860
The proposed fix is either to remove this constraint or expose a discoverable app-level override, such as a startup setting equivalent to
Application.ConstrainPopupsToWorkArea = false, while preserving the current default behavior for existing applications.