Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
walterlv opened this issue Jul 20, 2019 · 15 comments

Comments

@walterlv
Copy link
Contributor

commented Jul 20, 2019

  • .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:

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:

WPF window behavior

The same issue of Visual Studio

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

This comment has been minimized.

Copy link

commented Jul 20, 2019

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

This comment has been minimized.

Copy link

commented Jul 21, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 22, 2019

@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

This comment has been minimized.

Copy link
Member

commented Jul 22, 2019

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

Instead, you can use this AppContext switch.

@rladuca

This comment has been minimized.

Copy link
Member

commented Jul 22, 2019

@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

This comment has been minimized.

Copy link
Member

commented Jul 22, 2019

@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

This comment has been minimized.

Copy link
Member

commented Jul 22, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 22, 2019

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 rladuca self-assigned this Jul 22, 2019

@rladuca rladuca added this to the 3.0 milestone Jul 22, 2019

@rladuca rladuca added the area-netfx label Jul 22, 2019

@rladuca

This comment has been minimized.

Copy link
Member

commented Jul 23, 2019

Using OSGVSO bug 21846686 to track.

@grubioe grubioe modified the milestones: 3.0, Future Jul 24, 2019

@rladuca

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

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

@haruby511

This comment has been minimized.

Copy link

commented Aug 12, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

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

@rladuca

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

@haruby511 What Windows version are you seeing this on?

@haruby511

This comment has been minimized.

Copy link

commented Aug 13, 2019

@rladuca

Edition: Windows 10 Pro 64-bit

Version: 1903

Build: 18362.267

@rladuca

This comment has been minimized.

Copy link
Member

commented Aug 16, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.