Any element created on the titlebar is considered as a titlebar!

[ghost1372]

Describe the bug

When I collapse the NavigationView, I then select one of the items (which includes the submenu).
An item that is placed on the title bar is considered as a title bar, and places that can be dragged are dragged, and places that can be clicked are clicked.

this is how i define titlebar:

public void SetDragRegion(NonClientRegionKind nonClientRegionKind, params FrameworkElement[] frameworkElements)
{
    var nonClientInputSrc = InputNonClientPointerSource.GetForWindowId(Window.AppWindow.Id);
    List<Windows.Graphics.RectInt32> rects = new List<Windows.Graphics.RectInt32>();
    var scale = GetRasterizationScaleForElement(this);

    foreach (var frameworkElement in frameworkElements)
    {
        if (frameworkElement == null)
        {
            continue;
        }
        GeneralTransform transformElement = frameworkElement.TransformToVisual(null);
        Windows.Foundation.Rect bounds = transformElement.TransformBounds(new Windows.Foundation.Rect(0, 0, frameworkElement.ActualWidth, frameworkElement.ActualHeight));
        var transparentRect = new Windows.Graphics.RectInt32(
            _X: (int)Math.Round(bounds.X * scale),
            _Y: (int)Math.Round(bounds.Y * scale),
            _Width: (int)Math.Round(bounds.Width * scale),
            _Height: (int)Math.Round(bounds.Height * scale)
        );
        rects.Add(transparentRect);
    }
    if (rects.Count > 0)
    {
        nonClientInputSrc.SetRegionRects(nonClientRegionKind, rects.ToArray());
    }
}

and

ClearDragRegions(NonClientRegionKind.Passthrough);
SetDragRegion(NonClientRegionKind.Passthrough, PART_ContentPresenter, PART_FooterPresenter, PART_ButtonHolder);

full code available here:
https://github.com/WinUICommunity/WinUICommunity/tree/main/dev/Components/Controls/Ported/TitleBar

@pratikone Can you explain why this happens?
Is there a problem with my codes? Or is this a bug?

Steps to reproduce the bug

1.Create a titlebar
2.Create some element on titlebar (NavigationView + submenu)
3.try to click on first item

Expected behavior

No response

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.5.1: 1.5.240311000

Windows version

Windows 11 (22H2): Build 22621

Additional context

No response

[DarranRowe]

AFAIK, this is expected behaviour.
The way the custom title bar works is that it essentially makes the title bar region part of the client area of the window. If you dig deep enough into the implementation, you should find that it is implemented around DwmExtendFrameIntoClientArea.
For this custom title bar to work as a title bar, since it is part of the window's client area, the custom title bar must intercept input and make that input behave like the title bar. This is why InputNonClientPointerSource exists.
The other big issue here is that WinUI 3 doesn't draw using child windows. It uses its own implementation of the Visual Layer, and this is based upon Windows' DirectComposition. Because of this, you should expect the model to be something close to the DirectComposition model. From what I have seen, WinUI 3 uses the bottom layer for all regular, non external content and then the top layer for effects.
But this is important. Because all WinUI 3 content is just bitmaps drawn to the lower layer, there is no way for any of the WinUI 3 content drawn to the main window to get above the input interception of the main window. This means that if any stray WinUI 3 content gets drawn into the area defined as the title bar then you just cannot interact with it normally.

So the real bug here isn't that anything on the title bar is considered the title bar, but instead, WinUI 3 placed content at the top of the window without checking if there was a custom title bar. It can't just check if it is within the bounds of the client area, since the custom title bar is seen as part of the window's client area.

[pratikone]

This is an expected behavior. This is how titlebar apis work. They create a draggable region wherever you define and that acts like a titlebar region. You can infact have multiple.

Coming back to your problem, since you are already using low level non client apis, you can just disable them (using ClearRegionRect api) whenever NavigationView is open and setRegionRects when it is closed.
Infact, I am using the same method internally whenever ContentDialog is displayed. Benefit of source availability, I can share the exact place . https://github.com/microsoft/microsoft-ui-xaml/blob/winui3/release/1.5-stable/dxaml/xcp/components/WindowChrome/CWindowChrome.cpp#L370

In future, there can be better ways to solve it. For now, this is the best way. Since, it is by design, I am closing the bug. Feel free to comment if you have more related questions on it.