bug#8789: 23.3; debug backtrace buffer changes window on step-through

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

> 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.

What's more, in that same context, if I do not try to drag the frame but I
instead hit `d', I can step through the debugger once (a single `d').  The frame
is removed and re-created, and *Backtrace* shows the effect of stepping (one
step).

But at that point hitting `d' again or `c' or `q' has no effect.  Buffer
*Backtrace* remains frozen with its same state.  I need to select another frame
and hit `C-]' (abort-recursive-edit) to exit the debugger (which removes frame
*Backtrace*).

After hitting `d' once, I tried clicking mouse-1 inside *Backtrace*, thinking
that perhaps it did not have the focus.  That either had no effect (clicking `d'
etc. still did nothing) or it make the frame disappear and the debugger exit,
i.e., just as it does when I try to resize it.

If, instead of hitting `d' immediately, if I try to click mouse-1 inside
*Backtrace*, either #1 or #2 happens:

1. (a) the click has no effect - I cannot, for example, select text there by
dragging the mouse, and (b) the frame becomes insensitive to keyboard input:
even the first `d' is unrecognized.

2. The frame disappears and the debugger exits.

This is very weird behavior.  As I said before, none of this happens with the
Windows build of 2012-09-03.  It happens with the build of 2012-09-17.