bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics <rudalics@gmx.at>]

 > 1. Ensure, I think, that the only calls to `set-frame-size' are from
 > my calling `fit-frame' interactively (via C-x C-_).  Nothing on
 > `post-command-hook' that invokes `set-frame-size', for instance.
 >
 > 2. Resized a frame manually (with the mouse), so that the next call
 > to `fit-frame' would actually change the size (to fit the buffer text).
 >
 > 3. C-x C-_ (`fit-frame'), which fit the frame, with no loss of the
 > mode line.
 >
 > 4.  C-x C-_ again, which fit the frame (as a no-op, no size change
 > needed), this time with loss of the mode line (the bug).
 >
 > Attached is the log, *window-frame-dump*.  After #3, I added a
 > line of zeros to the buffer, to make clear where the second call to
 > `fit-frame' (hence `set-frame-size') occurred.

Thanks.  The problem is that while in the first dump Windows and Emacs
agree about the frame's pixel height as

frame pixel: 511 x 528   cols/lines: 73 x 44   units: 7 x 12
                    ^^^
frame text pixel: 490 x 528   cols/lines: 70 x 44
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 519 608), (0 0 511 528)
                                   ^^^
they disagree in all remaining dumps

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
                    ^^^
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
                                   ^^^
by 24 pixels, incidentally (maybe) the equivalent of two lines of 12
pixels.  Please try two things now:

(1) Repeat the test once with a default character height of 11 pixels
     and once with say 14 pixels so we can tell whether the two lines
     paradigm holds.

(2) Try to replace `fit-frame' by (set-frame-size nil 101 69) so we can
     eliminate `fit-frame' as possible source of the problem and have an
     easier repeatable scenario.

martin