Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!bloom-beacon!ginsu.apple.COM!davep
From: davep@ginsu.apple.COM
Newsgroups: comp.windows.x
Subject: Re: bug in xfig or twm
Summary: Xt bug triggered by twm & xfig,xbrowser,...
Message-ID: <8901182305.AA09594@ginsu.aux.apple.com>
Date: 18 Jan 89 23:05:45 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 50


I just spent a solid day debugging twm & xbrowser, and found a bug in
the intrinsics that would also cause problems in xfig and other
toolkit programs, as noted by Jay Waller and Sundar Narasimhan.
In <8901181543.AA09479@special-k.ai.mit.edu>, Sundar indicates that
awm may also trigger the problem, but less reliably.

The problem comes when using twm (without having NoTitleFocus set in
the .twmrc file) with an application that uses popup shells without
destroying them when it pops them down.  When the popup shell is
popped down, characters are no longer sent to text widgets in the main
window.  I will create a trivial example program and submit a bug
report to MIT, but I wanted to let people know what was happening.

Two possible workarounds are: a) call XtDestroyWidget to destroy the
widget after popping it down with XtPopdown, or b) set NoTitleFocus in
.twmrc.

When NoTitleFocus is set, twm explicitly sets the input focus to the
top-level client window when the pointer enters the frame window, by
calling XSetInputFocus.  Doing this causes the server to send the client
FocusIn and FocusOut events that don't normally get sent (run xev with
and without twm to see this).  The intrinsics handle these events by
calling InsertFocusEntry() and RemoveGrab() to modify the focusList in
lib/Xt/Event.c.

Normally there is only one entry on the focusList (for the active
shell window).  However, when you popdown a dialog without destroying 
it, RemoveGrab() doesn't get called on it.  InsertFocusEntry() does 
get called for the main window, as usual.  Now there are two entries 
on the focusList; the main window's entry is at the head of the list.

When keyboard input comes in, the FindFocusWidget() routine in Event.c
is called to determine what widget the event should be dispatched to.
There is a bug in FindFocusWidget() -- if the focusList entry it finds
is not at the end of the list, the "if (start == NULL)" test in the
while loop fails, and eventually it finishes the loop rather than
returning from the middle of it.  If the test had succeeded, it would
later have deduced that dst is an ancestor of widget, and returned
widget.  At the end of the routine, it merely returns dst (the
ancestor), which is the child of the top-level shell window.

Twm's behaviour here is reasonable, although the current implementation
of title focus (i.e., sending characters to the client window when the
pointer is in the frame window) can cause a delay in shifting the
input focus when moving the pointer to another top-level window.


Dave Payne		Apple Computer, A/UX Engineering Group, Cupertino, CA.
davep@apple.com		(408) 974-5545