After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 674124 - Button not responding due to focus problem
Button not responding due to focus problem
Status: RESOLVED DUPLICATE of bug 672193
Product: gtk+
Classification: Platform
Component: Backend: Quartz
2.24.x
Other Mac OS
: Normal normal
: ---
Assigned To: gtk-quartz maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2012-04-15 04:07 UTC by Steffen Gutmann
Modified: 2012-11-17 13:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Steffen Gutmann 2012-04-15 04:07:02 UTC
I noticed a focus problem that seems to exist since a while in gtk-osx.  I am running Lion 64bit with gtk+-2.24.9.  Here is how to reproduce it:

1. Start gtk-demo
2. Double-click on 'Dialog and Message Boxes'
3. A window with title 'Dialogs' appears.
4. Move this window over any other non-gtk window, e.g. a terminal window or Safari.
5. Click on 'Message Dialog'.
6. Click on 'Ok' in the new dialog window.
7. Now try clicking 'Message Dialog' again.  It does not take any input any longer.

It depends on over which items the mouse is moved when clicking 'Message Dialog' again.  If the cursor moves over other GUI elements it seems to generate focus-in/out events that make it work again.

If the 'Dialogs' window (step 4) is not over a non-GTK window (e.g. desktop background or another GTK window) then the problem does not show up.

Steffen
Comment 1 Clayton Walker 2012-05-10 17:00:18 UTC
I can confirm this.
Running Mac OSX 10.7.3 and gtk 2-24 master.
Pulling up an "about" dialog box can be closed with spacebar, but I can't click on the buttons.
Comment 2 dhertrich 2012-07-24 08:23:29 UTC
I have a similar problem on Lion with the application NoteCase Pro, that uses GTK+ 2.24.0 (I'm not a dev, only a user, but maybe this can add some valuable info, in case it is related to this ticket):

In situations where a dialog does not take mouse input anymore, it helps to *move* the dialog (grab title bar with mouse, move it only by a few pixels, then release it again), and afterwards the dialog widgets can be used with the mouse again.

Can you confirm this? So is the problem I observed the same as the one described by this ticket?

This is a big usability spoiler on OS X, so a fix for this would be important.
Comment 3 Paul Davis 2012-07-24 11:38:01 UTC
the fix for this is almost certainly in the attachment to bug 672193 .. i'd mark this as a duplicate though i'm not sure it is.
Comment 4 Kristian Rietveld 2012-07-24 11:57:34 UTC
I plan to have a look at both issues this week  (it's on my list of last things to look at).
Comment 5 Kristian Rietveld 2012-07-29 18:39:08 UTC
I cannot reproduce the test case from the opening comment with the latest gtk-2-24 from git.

I can reproduce the about box issue from comment 1. What appears to be happening in this case is that the enter notify (as per bug 672193) is sent correctly, however, *after* this synthesized enter notify we pass through an enter notify from the system on another window (presumably the window from which a menu item was activated). This messes up state and the active about box window never gets its designation as pointer window back until you click in it.

What needs to be seen is when the system is sending this enter notify and why exactly it is sent. Perhaps we are synthesizing our enter notify too early, or we shortcircuit the queue with append_event(), while we should be using another way to put the event on the queue such that it comes after the system enter notify.
Comment 6 Kristian Rietveld 2012-11-17 13:29:52 UTC
672193 will fix this.

*** This bug has been marked as a duplicate of bug 672193 ***