GNOME Bugzilla – Bug 658842
Fix win32 _gdk_windowing_window_at_pointer - port to gtk3
Last modified: 2018-05-02 15:13:57 UTC
Created attachment 196283 [details] [review] Patch to fix this issue Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct code to find the toplevel window. The WindowFromPoint() function does not return the toplevel window in the hierarchy. Only certain cases require decending into child windows. Also (for neatness), add tests to ensure that we don't try to return either x or y window coordinates if that corresponding pointer is NULL.
Ok - the version of the patch attached is not correct, as it cannot differentiate between OUR child windows of the desktop, and other process' windows. Sometimes ChildWindowFromPoint will return someone else's window.
Created attachment 196319 [details] [review] Alternative patch Alternative patch which may be closer to the required behaviour. This one ignores all hidden, disabled or transparent windows, although we "might" actually use transparent windows for INPUT_ONLY purposes.
Created attachment 196320 [details] [review] Alternative patch - keeping search for invisible windows etc.. This is the alternative, if we need to keep support for descending into invisible, disabled or transparent child windows.
And yet this _still_ causes trouble, due to the pesky synaptics touchpad driver which insists on poping up a stupid little icon window under the mouse pointer when you scroll.. This icon window is not ours, but is picked up in the WindowFromPoint() call as it is the topmost window at the mouse pointer location we probe. We then (of course), treat this as a leave event - as we find an alien window under the mouse pointer. Should we be trying to ignore this "leave" into the synaptics icon, or should we just let it happen - along with the rendering breakage we might get in applications (like the one I'm working on) which draw their viewport differently when the pointer is outside of it. (In this case, it is a cross-hair we switch off).
Review of attachment 196319 [details] [review]: This patch looks just right to me, its the same behaviour as the X11 backend.
Review of attachment 196319 [details] [review]: Actually, we use WS_EX_TRANSPARENT for input only windows, so it doesn't seem right to ignore those. And WindowFromPoint doesn't ignore these (as per the second footnote it http://blogs.msdn.com/b/oldnewthing/archive/2010/12/30/10110077.aspx )
Review of attachment 196320 [details] [review]: I don't think we need to decent into invisible children, at least the X11 backend doesn't do that (i verified that).
As for the synaptics issue, i think we need to do a bit more research into exactly what it does. Where in the hierarchy does it insert a window? What kind of window? Why doesn't this affect normal Win32 apps (getting a leave event)? etc... Then we can make a more educated decision on how to handle it.
The win32 webkit backend has some hacks for some trackpads: http://www.google.com/codesearch#N6Qhr5kJSgQ/WebKit/win/WebView.cpp Might be worth researching.
Here are some other hacks: http://www.google.com/codesearch#BwGY3OYFpeM/trunk/Fog/Fog/Gui/Engine/WinGuiEngine.cpp&l=1512 http://www.google.com/codesearch#Dc4_OXI0ClM/trunk/thirdParty/Qt/src/gui/kernel/qapplication_win.cpp&l=2827 http://www.google.com/codesearch#cFooKvxdTls/widget/src/windows/nsWindow.cpp&l=646
Comment on attachment 196320 [details] [review] Alternative patch - keeping search for invisible windows etc.. Obsolete, as we don't need to descend into invisible child windows
Created attachment 197196 [details] [review] Patch to fix this issue This version of the patch does not avoid descending into transparent child windows, as per Alexander's comment 6
Review of attachment 197196 [details] [review]: This looks good to me.
I pushed this to gtk-2-24, but keeping this open as we need to forward port this to gtk3.
Not skipping transparent windows does cause issues. See GIMP bug 780979 and friends (tl;dr, programs that use an always-on-top transparent window cause all sorts of input shenanigans with GIMP and other gtk2 programs.) In spite of what the TONT post from comment 6 says, WindowFromPoint() does seem to skip windows that have both WS_EX_TRANSPARENT and WS_EX_LAYERED set. Passing CWP_SKIPTRANSPARENT to ChildWindowFromPointEx() fixes these issues. It should be enough to do that only on the first call to ChildWindowFromPointEx() (or maybe, as long as window == NULL?), since we shouldn't hit any input-only gdk windows at that point.
I'm somewhat unsure why WS_EX_TRANSPARENT is to be used on input-only windows, and it's been bugging me for some time. Transparency-wise, it is completely useless (in the sense that you don't get any alpha-transparency for free when using this style). We get better alpha-transparency from the Window Manager. What it *does* do is affect the hit-test transparency, as mentioned in the post in comment 6. So why is a window that is *specifically* created to receive input is made transparent in such a way that it *can't* receive input? Mouse input, that is (since all hit-tests fall through - i'm using this feature in a pending DnD patch, where drag-indicator is made WS_EX_TRANSPARENT to prevent GTK from considering it as a valid drop target). This is all very confusing, and not documented as well as it should be...
For the record, in GIMP we have had a lot of focus/drag-n-drop issues on Windows because of Skype, antiviruses, screenshot/cast and other kind of programs. See bug 780979, all its duplicates and many more reports we had out of bugzilla as well. This has been going on for years. Ell's patch (cf. comment 15) will be used for GIMP's Windows binaries: https://git.gnome.org/browse/gimp/tree/build/windows/patches/gtk+-2.24-bug780979.patch At least the development ones so that we can have the various people reporting issues test and see if it really fixes these.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/370.