GridSplitter does not capture input

[stefankueng]

I'm submitting a...

• Bug report (I searched for similar issues and did not find one)

Current behavior

When moving a GridSplitter, the mouse pointer often moves outside the GridSplitter-Area, which is expected. But when that happens, the controls beside the GridSplitter still get pointer events.

Expected behavior

I would expect other controls to not receive pointer events at all during dragging a GridSplitter.

Minimal reproduction of the problem with instructions

Minimal Project: Create new "Windows Template Studio" c# project in VS, project type "Blank", leave the rest as default. Then edit the MainPage.xaml:

<Page
    x:Class="App1.Views.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:controls="using:Microsoft.Toolkit.Uwp.UI.Controls"
    Style="{StaticResource PageStyle}"
    mc:Ignorable="d">
    <Grid
        x:Name="ContentArea"
        Margin="{StaticResource MediumLeftRightMargin}">
        <Grid.RowDefinitions>
            <RowDefinition Height="40*"/>
            <RowDefinition Height="10"/>
            <RowDefinition Height="40*"/>
        </Grid.RowDefinitions>

        <Grid x:Name="top" PointerMoved="Top_PointerMoved" Background="White" ManipulationMode="All" VerticalAlignment="Stretch" HorizontalAlignment="Stretch"/>
        <controls:GridSplitter x:Name="splitter" Grid.Row="1"/>
        <Grid x:Name="bottom" Grid.Row="2" PointerMoved="Bottom_PointerMoved" Background="AliceBlue" ManipulationMode="All" VerticalAlignment="Stretch" HorizontalAlignment="Stretch"/>
    </Grid>
</Page>

Views.zip

and in the code-behind (MainPage.xaml.cs):

private void Top_PointerMoved(object sender, Windows.UI.Xaml.Input.PointerRoutedEventArgs e)
{
    System.Diagnostics.Debug.WriteLine("pointer moved top");
}

private void Bottom_PointerMoved(object sender, Windows.UI.Xaml.Input.PointerRoutedEventArgs e)
{
    System.Diagnostics.Debug.WriteLine("pointer moved bottom");
}

Run the project, then move the GridSplitter. You'll get lots of debug messages printed while dragging the splitter.

Environment

Nuget Package(s): 
Microsoft.Toolkit.Uwp.UI.Controls

Package Version(s): 
latest stable: 5.0.0

Windows 10 Build Number:
- [x] October 2018 Update (17763)

App min and target version:
- [x] April 2018 Update (17134)
- [x] October 2018 Update (17763)

Device form factor:
- [x] Desktop

Visual Studio 
- [x] 2017 (version: 15.9.4)

[skendrot]

I'm not sure how this is a bug. If I depress the mouse on a button and move the mouse off the button the controls will receive mouse events as well

[stefankueng]

I think it's a bug: while dragging the splitter, the mouse should ideally stay on the splitter (the splitter moves with the mouse), but due to lags the splitter is usually a little behind. But in that case I don't want mouse events to happen on other controls.

If you depress the mouse on a button and then move the mouse off the button, but you expect the button to move (you're dragging the button), then you wouldn't expect other controls to receive mouse events, do you?

For example: if you drag a scrollbar bar and you move slightly off the bar into the main window while you're dragging it, the main window won't receive mouse events either - because at that time you're dragging the scrollbar bar.

My problem is this: While dragging the splitter, the resized panels receive mouse events, namely pointer-move events. One of the resizing panels then interprets these events: uses moves mouse while having the left mouse button pressed. And since it's an ink panel it draws garbage with the currently active pen-style and color. And it's garbage because the user was dragging the splitter, not drawing.

[windowstoolkitbot]

This issue seems inactive. Do you need help to complete this issue?

[windowstoolkitbot]

This issue seems inactive. Do you need help to complete this issue?

[windowstoolkitbot]

This issue seems inactive. It will automatically be closed in 14 days if there is no activity.

[windowstoolkitbot]

Issue is inactive. It was automatically closed.