bug#15016: 24.3.50; return of #8789: touch border of *Backtrace* frame > it disappears (exits)

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

I am now seeing again the behavior I reported in the middle of the
discussion of bug #8789, which I thought had been fixed:

When I touch mouse-1 to the *Backtrace* frame border, to try to widen
the frame (because the debugger frame now insists upon reinitializing
itself instead of remembering the last width I dragged it to...), the
frame immediately disappears and the debugger is exited.

Quite frustrating to use...

Again, the context is using `debug-on-entry' for a function that is
invoked when the minibuffer is active - for example, a function used to
sort candidates in *Completions*.

Here is the relevant description from bug #8789:

> Sent: Wednesday, September 19, 2012 9:46 AM
...
> 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
> described earlier).
> 
> 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.
> 
> Very weird.  I'm sorry that I cannot offer more info about this.  But
> clearly something is very wrong.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-07-21 on ODIEONE
Bzr revision: 113485 lekktu@gmail.com-20130722012547-e3b7qxn1dba5vf20
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'