GNOME Bugzilla – Bug 597386
Cannot click buttons more than once without moving the mouse cursor
Last modified: 2009-12-17 19:21:37 UTC
This bug was reported at https://bugs.edge.launchpad.net/ubuntu/+bug/441905: "Nautilus: For example the zoom-buttons. Mouse is over the zoom-in-button. By clicking it's zooming in, but if you don't move the mouse, the button-border clears out. So the next click is without reaction. Only a slight moving with the mouse reactivate this button. Various buttons in nautilus haves the same strange behaivor. (go-back, go-up, etc. etc.) Evolution: If I click on send/recive it's working as usual. But the button-border around clears out - so the next click is without effects. Only if you move the mouse a little bit you get a clickable button again. I don't know which package is provocating it, but it's affects various programs like nautilus, evolution etc. It's a uncomfortable bug, because the nautilus-example with the zoom you're clicking fast and continuous for reach your percent of zooming. This bug makes uncomfortable the "goes"-buttons, too. It's making a fast using of those buttons impossible." This behavior started after 2.18.0. I've bisected this, and the bad commit is this one: 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 is first bad commit commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 Author: Alexander Larsson <alexl@redhat.com> Date: Mon Sep 28 15:21:54 2009 +0200 Extend _gdk_windowing_window_at_pointer to be able to get toplevels only This has two advantages: 1) In many backends, this is faster as we can terminate the window hierarchy traversal earlier 2) When used in gdkdisplay.c::get_current_toplevel() to get the current toplevel that has the pointer we now correctly return a toplevel with the pointer in it where the pointer is inside some foreign subwindow of a toplevel window. The second advantage fixes some bugs in client side event generation when the pointer is inside such a foreign child window. :040000 040000 0bf878a4bdc90edc26e1fabca17810153eab556d 3b77b97a97805a1fe60cee79033e1a7fec10bdb6 M gdk The full bisect log: git bisect start # bad: [05ded28d7d282bed6de457edeeb3e1461ea0d0ac] Updated Japanese translation git bisect bad 05ded28d7d282bed6de457edeeb3e1461ea0d0ac # good: [b841251ca79c332fd9922973b2a40e1298ae7f47] 2.18.0 git bisect good b841251ca79c332fd9922973b2a40e1298ae7f47 # bad: [6fef640debbe468586ff866cbef38d7a29c452d1] Only select for button and pointer event on toplevels git bisect bad 6fef640debbe468586ff866cbef38d7a29c452d1 # good: [06c208f8f1db10fc46ea44dc06fdd92b76467b4f] Updating Estonian translation git bisect good 06c208f8f1db10fc46ea44dc06fdd92b76467b4f # good: [f2d9f5a9e6d4d9d3de1510b39d9a0ce0a976a4b3] Remove unused variable git bisect good f2d9f5a9e6d4d9d3de1510b39d9a0ce0a976a4b3 # bad: [e81501ebea4cceffce2890519807b0c243fec0a3] Sent button events don't cause passive grabs git bisect bad e81501ebea4cceffce2890519807b0c243fec0a3 # bad: [5ebb32d1ffa23241d562fb4d5be02bc6f156b515] Extend _gdk_windowing_window_at_pointer to be able to get toplevels only git bisect bad 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 # good: [fe188a18f324f4545af857436a6060e676a1287d] Bug 596494 - New property "cursor" in 2.18's GdkWindow with wrong type? git bisect good fe188a18f324f4545af857436a6060e676a1287d
Actually, the source of the error is this: http://git.gnome.org/cgit/gtk+/commit/?id=5ebb32d1ffa23241d562fb4d5be02bc6f156b511 I fixed it with: http://git.gnome.org/cgit/gtk+/commit/?id=786b589d95077b465dcc2311ff2489ee7bb9a49f But we need to get a new release out with this fix soon.
*** Bug 597257 has been marked as a duplicate of this bug. ***
*** Bug 597258 has been marked as a duplicate of this bug. ***
*** Bug 597621 has been marked as a duplicate of this bug. ***
In a two screen (non xinerama) multihead setup, this or a closely related bug reappears. An application with two top level windows meant to run each on its own monitor that is a separate X display, that is: the app moves one window to be on the other (non launching) screen-- will cause all toggle and simple buttons only on the non-launching screen to permit only one click until the mouse is moved off the non-launching screen, or until a dropdown combo-box on the non-launch screen changes value. Toggle and simple click buttons in the window on the launching screen are normal. Recompiling the application so that both top level windows use one screen (simply commenting out the lines that move one of the two to another screen) causes everything to work normally. I tried launching this 'one screen two windows' version on each of the two screens/monitors -- normal in that case. This is on an amd64 gtk v2.18 multi-head multi-thread debian/squeeze box. Consider changing this bug to re-opened?
Created attachment 149073 [details] [review] Possible fix I think this will help, can you test it?
Fix Confirmed. This fix works on amd64 gtk 2.18.3 debian squeeze 2 monitor, 1 top level window per, display. Thanks!!
fixed on master and gtk-2-18 branch
This thread shows why open source development offers more. I had a similar problem with Windows Vista a while back. Though I spent a great deal of time proving and identifying the multi-monitor related bug, as it was in their code I needed Microsoft to fix it. I lost a year of sales and development time and even more time convincing people in on the telephone in India that they did not have the fix already in their bag of trick. Finally I get to a person in Redmond, WA who does the whole engineering thing, sending me fixes to test. In exchange for halting forward progress I was not offered an in-kind extension to my 'developer's kits subscription' in exchange for the year I lost. However, they did offer me the chance to help them debug Windows 7 before it was released, as well as paying them for access to the developers kit materials. That's why this new multi-monitor application is gtkbuilder/gtk/linux based.
Btw, any particular reasons you use multiple screens rather than a "large virtual monitor" kind of approach that is the "modern" way to do multi-monitor support (as per xrandr, etc). If you'd use the later then you could use APIs such as: gint gdk_screen_get_n_monitors (GdkScreen *screen); void gdk_screen_get_monitor_geometry (GdkScreen *screen, gint monitor_num, GdkRectangle *dest); gint gdk_screen_get_monitor_at_point (GdkScreen *screen, gint x, gint y); To handle the user-setup monitor geometry.
The need sort of 'grew' after using the sort you mentioned hit some bumps. Generally the issue had to do with the user's desire to have 'maximize' on any application just full one physical monitor in the group. Actually I do have multi-monitor setups that use 'xinerama' and appear as if it was one very large monitor. There are two, perhaps three applications that need each display in its own little world. Unless I've missed something, having each monitor as it's own X display is required to use concepts like 'full screen mode' when the intent is to use an entire monitor borderlessly while using other monitors in the usual 'task bar, launch menu multi-app way'. For example I have one development environment that has two monitors arranged vertically left of the operator using Nvidia's ability to have them act like one X display (multi-tab iceweasel used for documentation viewing), another two similarly to the right of the operator for a total of 2 displays (source code editing). Two more monitors vertically right in front of the operator each as it's own display, usually as remote desktop clients to elsewhere or debug runs of an application being debugged and an email client/etc, with another single monitor far off on the right acting as a video-streaming client. Basically it is a big desk for someone that needs a bigger electronic desk than physical desk space. The second application where each monitor is it's own X display is when the operator moves the monitors around from time to time relative to each other and isn't able/interested in learning how to tell the software about that change. Needs to be able to launch an application from whichever monitor they happen to be in front of at the moment whether or not the other has a full-screen application running. They just wave the mouse around until they see it, and then work away. The last use has the same general theme, the monitors change sizes and/or resolution needs change often and it is just too much fuss to try to make it all play nicely with other monitors as one big virtual X display. So each has it's own ability to launch apps and everyone is happy. Obviously the application can't be 'grown' to extend across monitors in that case but the resolutions are high enough that the user prefers 'full screen' mode to take one full screen without dragging and sizing. I suppose it mostly could be avoided if the railroad that runs between 'minimize' 'windowed' and 'maximize/fullscreen' instead went 'minimize' 'windowed' 'fill one monitor' 'fill whole multimonitor display'. So, change right clicking 'maximize' to use go fullscreen on one monitor, while some other choice meaning 'maximize to whole virtual multimonitor display'.
In xrandr each "screen" has multiple monitors, so if you maximize a window it fills only the monitor, however you *can* drag it so it overlaps both. However, there still has to be some defined orientation as the mouse moves from one monitor to the other when it reaches the right borders, so it doesn't work if the monitor moves around and suchlike.