bug#13114: 24.3.50; can no longer use debugger in separate frame: frame disappears

["Drew Adams" <drew.adams@oracle.com>]

This problem or something very similar appeared several months back,
when Martin was working on fixing some display-buffer problems - see bug
#8789.  I thought this was fixed, but recently it seems to be back.
 
I use a separate, special-display frame for *Backtrace* (and for other
buffers whose names are of the form `*...*').
 
Frame *Backtrace* gets created OK (but once it did not - a weird error
was raised - see bug #13113).  But as soon as I click any part of it
with the mouse (e.g. mouse-1), that frame disappears completely.
 
I cannot use the debugger at all.
 
Here was what I said in bug #8789, for info:
 
  Sometimes I can grab the border of the *Backtrace* frame, as usual,
  and resize it (even though it goes back to the default size when I hit
  `d', as describedearlier).
 
  But sometimes I cannot: as soon as I touch the mouse to the frame edge
  and try to drag it, the frame disappears!  I can just touch it (e.g.
  click it) without it disappearing, but as soon as I try to drag the
  touched edge, the frame disappears.  It does not matter which edge
  (e.g. bottom or right) I try to drag.
 
  No idea what is going on here - I have never seen anything like this.
 
  This happpens systematically when I enter the debugger in a certain
  context, and it never seems to happen otherwise.  But that context
  is far too complex to try to communicate.  Suffice it to say that
  this happens.
 
  When it happens I see nothing additional in *Messages*, and there is
  no crash.  The *Backtrace* frame just disappears, and the mode line
  indicates that I am no longer in a recursive edit - IOW, the debugger
  is exited.  And if I explicitly visit buffer *Backtrace*, I see that
  it is indeed empty.
 
  It is as if trying to drag the frame edge is (sometimes) the
  equivalent of hitting `q' in the debugger.
 
But now it is not only trying to drag the frame border that causes
this.  Any mouse click on the frame, anywhere, causes it.
 
I mention that older bug here because Martin apparently recognized the
frame-disappearance problem (& cause?).  He immediately replied: "This
should have changed now."  And indeed, it did seem to be fixed.  IOW,
presumably he or someone else made some change that helped.  I'm hoping
that the same or similar fix can be made now, or at least that that
previous bug report will help someone fix this current problem.
 

In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-12-03 on MS-W7-DANI
Bzr revision: 111077
agustin.martin@hispalinux.es-20121203172342-ifsebjmhksk28qa9
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
 -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'