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 126727 - GOK getting focus due to gtk+ internals change
GOK getting focus due to gtk+ internals change
Status: RESOLVED FIXED
Product: gok
Classification: Deprecated
Component: general
unspecified
Other All
: Urgent critical
: ---
Assigned To: bill.haneman
Metacity maintainers list
AP0
: 127395 128438 (view as bug list)
Depends on: 64613
Blocks: 128438 128692
 
 
Reported: 2003-11-11 14:53 UTC by bill.haneman
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
small test program to illustrate the problem, test-focus-reject.c (2.36 KB, text/plain)
2003-11-13 14:46 UTC, bill.haneman
  Details
Proposed patch (1.19 KB, patch)
2003-11-17 15:59 UTC, padraig.obriain
none Details | Review
Stack trace of when update_wm_hints is called (4.68 KB, text/plain)
2003-11-18 08:47 UTC, padraig.obriain
  Details
Patch for gok after fix for bug #64613 (556 bytes, patch)
2003-12-11 09:53 UTC, padraig.obriain
none Details | Review
Updated patch (2.30 KB, patch)
2003-12-11 10:44 UTC, padraig.obriain
none Details | Review

Description bill.haneman 2003-11-11 14:53:14 UTC
metacity is now focussing the GOK window, after upgrading to gtk+ 2.3
series (i.e. HEAD).  (I haven't upgraded metacity, so this bug might end up
being transferred to gtk+ soon)

GOK attempts to reject focus by registering a filter when 'realize' is
called for the GOK window; the filter code is shown below:


GdkFilterReturn
gok_discard_focus_filter (GdkXEvent *xevent,
                          GdkEvent  *event,
                          gpointer  data)
{
  XEvent *xev = (XEvent *)xevent;
  GList *list, *l;
  gint n_mapped;
  GtkWindow *window;
  gboolean has_focus;
                                                                          
      
  if (xev->xany.type == ClientMessage &&
      (Atom) xev->xclient.data.l[0] == gdk_x11_atom_to_xatom (
              gdk_atom_intern ("WM_TAKE_FOCUS", False)))
    {
      list = gtk_window_list_toplevels ();
      n_mapped = 0;
      has_focus = FALSE;
      for (l = list; l; l = l->next)
        {
          if (GTK_WIDGET_MAPPED (GTK_WIDGET (l->data)))
            {
              n_mapped++;
              window = GTK_WINDOW (l->data);
              if (window->has_focus)
                has_focus = TRUE;
            }
        }
      if (!has_focus && n_mapped > 1)
        XSetInputFocus (xev->xany.display, GDK_WINDOW_XID (GTK_WIDGET
(window)->window), RevertToPointerRoot, CurrentTime);
                                                                          
      
      g_list_free (list);
      return GDK_FILTER_REMOVE;
    }
 ...


This works fine with gtk+-2.2 but doesn't work anymore.  What gives?
Comment 1 David Bolter 2003-11-11 19:09:40 UTC
I can confirm this (using gnome build from Nov 5th)
Comment 2 bill.haneman 2003-11-12 14:07:47 UTC
changed severity to 'critical' because, although not a build blocker
or SEGV, it makes a core desktop component unusable.  reasonable?

I am doing some diagnostics to see if the filter-func is getting called.
Comment 3 bill.haneman 2003-11-12 14:11:22 UTC
David: just as a reality check, can you confirm that this happens with
an older version of GOK? i.e. do a cvs checkout from a few weeks back
and build/install.  Or perhaps build-install glib/pango/gtk+ 2.2.X
instead of 2.3.X.  It'd be nice to be sure which module's behavior has
changed, i.e. glib, gtk+, metacity, or gok.  My evidence points to
gtk+/glib since I haven't upgraded metacity and gok was working prior
to switching gtk+ versions, but it's really easy to accidentally get
confused about what got installed when ;-)  thanks.
Comment 4 David Bolter 2003-11-12 14:50:54 UTC
It is difficult for me to test this since my hard drive is bursting at
the seams and I use the sun gnome build tarballs, deleting the old
tree when I install the new one. This definitely started happening
right after I updated to the latest sun gnome build for redhat.
Perhaps David H could test this?  Is DH over there in Ireland?
Comment 5 bill.haneman 2003-11-13 14:46:35 UTC
Created attachment 21410 [details]
small test program to illustrate the problem, test-focus-reject.c
Comment 6 bill.haneman 2003-11-13 14:49:45 UTC
Havoc and Owen:

I attached a small test program to illustrate the issue.  Of course
this breaks GOK completely since an onscreen keyboard is of no use if
it steals focus from the app you're trying to enter keystrokes into :-)

The code for WM_TAKE_FOCUS, i.e. get the event and then do nothing,
has always worked in the past.  Also I can confirm that the gdk filter
is getting called. 

Looks like a metacity bug, but seems to have only been exposed by
switch to gtk+ HEAD, which seems a bit odd.
Comment 7 padraig.obriain 2003-11-17 15:24:08 UTC
It looks like a change in gtk+, probably gdk, has caused this problem.
I will try to narrow it down further.
Comment 8 padraig.obriain 2003-11-17 15:59:23 UTC
Created attachment 21537 [details] [review]
Proposed patch
Comment 9 Owen Taylor 2003-11-17 16:05:28 UTC
A) Can you *explain* the patch
B) Introducing a round-trip here is not acceptable.

It may not be possible to fix this without introducing new
GDK API. 

(Note that there are no compatibility guarantees for 
applications that change the hints that GDK sets on 
X windows after GDK sets them. There's just no way we
can make that guarantee and retain the ability to
make forward progress.)
Comment 10 padraig.obriain 2003-11-17 16:19:52 UTC
gok and the attached test program calls XSetWMHints with flags set to
InputHint and input set to False. This is so that gok main window is
not given focus.

This setting is overwritten by the call to XSetWMHints in
update_wm_hints.

It does look like GDK needs new API that gok can call instead of
XSetWMHints.
Comment 11 bill.haneman 2003-11-17 17:13:25 UTC
owen:

the method used by GOK (calling XSetWMHints) is what you yourself
recommended.  New API is not the nicest solution since that won't be
backwards compatible.

IMO changing hints after emission of the 'realize' signal is broken. 
Can't we just make gdk change hints _after_ realize?  or does that not
work due to window mapping... ?

Is there an event we can listen for that's guaranteed to be emitted
_after_ gdk has done all its X tweaking with the window?

Let me see if I have this straight; the problem is not with
TAKE_FOCUS, but with the fact that the 'INPUT' hint is overriding the
TAKE_FOCUS policy?  Is the WM supposed to focus a TAKE_FOCUS window
without an explicit SetFocus call from the app?  Thanks for clarifying.
Comment 12 Owen Taylor 2003-11-17 19:58:11 UTC
I suspect that any mention I made of XSetWMHints was prefaced
with some disclaimer like "we won't break this in the GTK+-2.2 
series, but long term, there's no guarantee one way or the 
other"

Trying to fix how GDK interacts with X is *not* something we
can do.

A breakpoint and backtrace in your example will reveal why
GTK+ is resetting the Wm hints. It might be a bug/inefficiency,
it might be needed.

Certainly GTK+ can't guarantee that it won't call XSetWMHints
after realization ... if someone changes the Icon, GTK+ needs
to change the WM Hints. And that could happen at any time
the app decided to do so.

The ICCCM describes what different combinations of WM_TAKE_FOCUS
and the input hint mean. WM_TAKE_FOCUS+Input is the 
"locally active model", which means "give me the focus, but
also send a WM_TAKE_FOCUS message so that I can move it elsewhere"
inside the toplevel. Input alone just means "just give me the focus"
Comment 13 Matthias Clasen 2003-11-17 22:14:35 UTC
See also bug 64613 for related discussion of "output only" windows.
Comment 14 padraig.obriain 2003-11-18 08:47:42 UTC
Created attachment 21574 [details]
Stack trace of when update_wm_hints is called
Comment 15 bill.haneman 2003-11-18 12:55:20 UTC
we need to escalate the API issue then, and quickly, since this
completely breaks GOK and there doesn't appear to be a reliable
workaround (unless we can suppress the set_icon call be, perhaps,
calling it prior to gtk_window_show()).  Even then, it wouldn't be a
reliable long-term solution.
Comment 16 Owen Taylor 2003-11-18 15:23:19 UTC
I think the backtrace above is the *first* call of update_wm_hints(),
before the manual tweaking of the input hint is done, so doesn't
really show what's going on.

Duping on 64613, since the conclusion here seems to be that
we need to add new API.


*** This bug has been marked as a duplicate of 64613 ***
Comment 17 bill.haneman 2003-11-18 15:53:28 UTC
owen:

Duping this loses the GOK context.  I'd like to reopen it for that
reason; although the resolution may be "add API", the current
behavioral bug is already present and is a user regression.
Comment 18 bill.haneman 2003-11-18 15:54:41 UTC
owen: note that this is 'AP0' so we need to keep this for
accessibility bug tracking purposes.
Comment 19 Owen Taylor 2003-11-18 16:20:48 UTC
Please reassign to GOK, then.
Comment 20 bill.haneman 2003-11-18 18:42:25 UTC
(reluctantly) reassigning to GOK.
Comment 21 David Bolter 2003-11-19 15:20:52 UTC
*** Bug 127395 has been marked as a duplicate of this bug. ***
Comment 22 bill.haneman 2003-12-04 13:49:03 UTC
removing PATCH keyword since patch is not acceptable to GTK+ maintainers.
Comment 23 bill.haneman 2003-12-09 16:01:01 UTC
*** Bug 128438 has been marked as a duplicate of this bug. ***
Comment 24 padraig.obriain 2003-12-11 09:53:27 UTC
Created attachment 22326 [details] [review]
Patch for gok after fix for bug #64613
Comment 25 bill.haneman 2003-12-11 10:15:41 UTC
Padraig: Thanks!  This is excellent.

I think perhaps we can remove the focus-handler gdkfilterfunc from gok
also, it's either in gok-main.c or callbacks.c.  Do you want to
prepare the patch and apply or should I?  I don't mind in the least. 
Or maybe I am misunderstanding...
Comment 26 padraig.obriain 2003-12-11 10:36:56 UTC
I will check.
Comment 27 padraig.obriain 2003-12-11 10:44:26 UTC
Created attachment 22330 [details] [review]
Updated patch
Comment 28 bill.haneman 2003-12-11 10:48:19 UTC
thanks Padraig.  Not sure we need the WM_TAKE_FOCUS protocol
registration in main.c either; I'm checking to see if it's needed.
Comment 29 bill.haneman 2003-12-11 11:01:40 UTC
it appears that the WM_TAKE_FOCUS protocol request in main.c is still
needed, otherwise the GOK main window sometimes gets focus despite the
gtk+ patch.  Maybe this is a gtk+ bug, but still...

Please feel free to commit the patch as revised, or I'll do it.
Comment 30 padraig.obriain 2003-12-11 11:04:23 UTC
I was trying to put this into the bug report but you beat me to it. It
looks like a bug in gtk. I will commit the patch to gok.
Comment 31 padraig.obriain 2003-12-11 11:13:23 UTC
Patch committed to CVS HEAD.