All WPF applications fail to drag outside of their windows since Windows 10 (1809/1903) such as resizing the window or do drag drop

[walterlv]

• .NET Core Version: 3.0 Preview6
• Windows version: 10.0.18362.116 (1903); 10.0.18941.1001 (Insider Preview)
• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes

Problem description:

All WPF applications fail to drag outside of their windows since Windows 10 (1809/1903) such as resizing the window or do drag drop. I find that most computers don't have such a bug but I also find out several others suffer from this issue.

I've posted this bug here several months ago:

• Why all my WPF applications fail to drag outside of their windows since Windows 10 (1809/1903) such as resizing the window or do drag drop? - Stack Overflow

I guessed it was the bug of Windows 10, so I just posted a Windows 10 Feedback via the Feedback app and publish it via StackOverflow. But day after day, I found that more and more people are suffering from this issue. So I think it may be both the bug of WPF and Windows.

It first reproduces in the 1903 Insider Preview and after the release of 1903, it still exists.

Actual behavior:

Expected behavior:

The window resizing behaves normal.

Minimal repro:

I can't find out the reproduction. But If one computer has such a bug, It will not restore back to normal even if the Windows 10 reinstall cleanly.

I've found that if I remove my nVidia video card hardware, the problem disappears. But I've asked some one others who have the same issue, he even has no external video card.

[mgnslndh]

I have observed the same behavior when resizing the window as well as dragging the window by the title bar.

Dragging and resizing works if I slowly move the mouse in such a way that the mouse does not leave the window.

I could reproduce this issue using the default WPF app template in Visual Studio. Not sure if it would repo on other hardware/OS combinations.

Video Card: Intel(R) HD Graphics 530

[mgnslndh]

Markus Eisenstöck found a work around for this issue. By disabling the tablet support in WPF you will experience the expected behavior. I have tested and it works on my machine (Windows 10 version 1903 & .NET Framework 4.6.2):

public static void DisableWpfTabletSupport()
{
    // Get a collection of the tablet devices for this window.    
    TabletDeviceCollection devices = System.Windows.Input.Tablet.TabletDevices;


    if (devices.Count > 0)
    {
        // Get the Type of InputManager.  
        Type inputManagerType = typeof(System.Windows.Input.InputManager);


        // Call the StylusLogic method on the InputManager.Current instance.  
        object stylusLogic = inputManagerType.InvokeMember("StylusLogic",
                    BindingFlags.GetProperty | BindingFlags.Instance | 
                    BindingFlags.NonPublic,
                    null, InputManager.Current, null);


        if (stylusLogic != null)
        {
            // Get the type of the stylusLogic returned 
            // from the call to StylusLogic.  
            Type stylusLogicType = stylusLogic.GetType();


            // Loop until there are no more devices to remove.  
            while (devices.Count > 0)
            {
                // Remove the first tablet device in the devices collection.  
                stylusLogicType.InvokeMember("OnTabletRemoved",
                        BindingFlags.InvokeMethod | 
                        BindingFlags.Instance | BindingFlags.NonPublic,
                        null, stylusLogic, new object[] { (uint)0 });
            }
        }
    }
}

[walterlv]

@mgnslndh Thanks for your solution and it helps some WPF applications works find just as other non-WPF applications. But this issue affects all WPF applications in a Windows 10 including Visual Studio, so it should be fixed in WPF framework or Windows 10.

[rladuca]

Do not use private reflection to disable stylus and tablet support in WPF.

Instead, you can use this AppContext switch.

[rladuca]

@grubioe I'm going to take this in light of some investigations I am doing into the same bug as reported internally on .NET Framework. I'm going to leave this unassigned for the time being so we pick it up in triage.

[rladuca]

@mgnslndh By the way, regardless of reflection vs the switch, thanks for your work in finding this out. It helps to pinpoint where some things might be going wrong. I have a strong feeling that something changed in the latest versions of Win10 and that messages we would normally receive are being "eaten" by WISP in the delegated input thread that it spawns to intercept WM_POINTER. I'll be looking into that today and seeing what I can find.

[rladuca]

I've confirmed that WM_MOUSEMOVE messages are not making it to the message loop in this situation when WISP is loaded in Win10 May 2019 Update.

With touch turned off, we seem to get normal mouse messages as expected.

I'm debugging into WISP now to understand if it is receiving all the messages and what it is doing with them.

[rladuca]

I found out some more.

• If you run a WPF application on a non-touch machine (say just disconnect a touch screen) and you connect a touch screen later, it all seems to work fine.
• If the screen is connected at app startup, the behavior repros.
• If you then disconnect the screen and wait some time, the behavior is fixed.

This seems to indicate to me that there is some installed hooks from WISP that are badly interacting with some OS change. I am going to file a bug on the OS input team to get this fixed.

[rladuca]

Using OSGVSO bug 21846686 to track.

[rladuca]

Was duped to 21929858 and the team has root caused it and is testing fixes for 19H1.

[haruby511]

I have same issue.

I'm using Wacom tablet. It actually work if unplug the tablet @rladuca as mentioned.

I hope this issue being fixed without disabling the stylus or tablets because my some WPF apps need to support pen pressures.

[rladuca]

A fix was recently made in the development branches of Windows. I am inquiring as to a servicing fix.

[rladuca]

@haruby511 What Windows version are you seeing this on?

[haruby511]

@rladuca

Edition: Windows 10 Pro 64-bit

Version: 1903

Build: 18362.267

[rladuca]

This has been queued up for 19H1 servicing.

I don't have a solid date for when this will ship, but it will be fixed in an upcoming service update.

@grubioe Can we update when have more clarity on a ship date?

[grubioe]

This is targeted for a fix in early October

[walterlv]

@grubioe Since my Windows 10 Insider Preview is updated to 10.0.18975.1000, I find that this issue is fixed. Thanks for fixing that.

@mgnslndh @rladuca @haruby511 Good News! This issue is fixed in the insider preview and will be fixed in 19H2 release.

[ghost]

Looks like the fix is out:
https://support.microsoft.com/en-us/help/4517211/windows-10-update-kb4517211
"Addresses an issue with resizing Windows Presentation Foundation (WPF) applications; they may not respond to being resized using the mouse until you release the mouse button."

[grubioe]

Yes, the fix was released this morning. Thanks all for the feedback. Closing issue.

[haruby511]

@grubioe Nice work!

BTW, I can see the KB4517211 as an optional update.

Is the update will included in next major version? Such as 19H2.

If not, should I notice all of the clients must install this update manually themselves every time?

[grubioe]

The update will rollout to all machines on October 8th, aligned with Patch Tuesday security updates.

…

________________________________ From: Jong-il Hong <[email protected]> Sent: Thursday, September 26, 2019 9:17 PM To: dotnet/wpf Cc: Gustavo Rubio; Mention Subject: Re: [dotnet/wpf] All WPF applications fail to drag outside of their windows since Windows 10 (1809/1903) such as resizing the window or do drag drop (#1323) @grubioe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgrubioe&data=02%7C01%7CGustavo.Rubio%40microsoft.com%7C63a97d9d06314686aa0008d74301a5d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637051546677006872&sdata=IJNgkyRCctc07XnlJwX5Z6DbvtOuCnVRTO48eW4eg%2Fo%3D&reserved=0> Nice work! BTW, I can see the KB4517211 as an optional update. Is the update will included in next major version? Such as 19H2. If not, should I notice all of the clients must install this update manually themselves every time? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fwpf%2Fissues%2F1323%3Femail_source%3Dnotifications%26email_token%3DALWN7UZDLHTVLBPR5SUOLULQLWCOTA5CNFSM4IFNMFZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7XVMVY%23issuecomment-535778903&data=02%7C01%7CGustavo.Rubio%40microsoft.com%7C63a97d9d06314686aa0008d74301a5d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637051546677016866&sdata=WVEO8alTZIb7qaud2y4xdyEHCjqfJkWF2EaYY93SZnU%3D&reserved=0>, or mute the thread<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALWN7U3D4K4MP4VTTV6X22DQLWCOTANCNFSM4IFNMFZQ&data=02%7C01%7CGustavo.Rubio%40microsoft.com%7C63a97d9d06314686aa0008d74301a5d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637051546677016866&sdata=L273b7KR2kjlPyDngxYZulY%2BHpFPsTCmY2LtwWkivNg%3D&reserved=0>.