With emacs -Q use the mouse to drag the bottom edge of your frame up as
far as possible.  With GTK builds I see menu and tool bar and one line
of *scratch*, with a Lucid build only menu and tool bar remain visible.

Apparently, Emacs handles such resizing well but under the hood there is
one slightly devastating difference: The GTK3 build is not aware of the
last resizing steps.  Evaluating (frame-height) in the final one line
frame yields 4, so Emacs misses three lines.  In GTK2 and Lucid we get 3
but this is an Emacs internal issue.  If you do

(setq window-safe-min-height 0)

before dragging the border, you get 1 as expected.

You can visualize the difference better by evaluating

(setq frame-size-history '(100))

before dragging, evaluating

(frame--size-history)

when dragging finished and inspecting the buffer *frame-size-history*.
Here I get for a GTK2 build (only the lines with <= 144 pixels listed)

Frame size history of #<frame *scratch* - GNU Emacs at restno 0x190aac0>
xg-frame-resized	 (720 144 720 126) nil
adjust-frame-size-1	 (720 144 720 126) (change-frame-size 5)
adjust-frame-size-3	 (720 144 720 126) (752 144 752 126)
xg-frame-resized	 (720 126 720 108) nil
adjust-frame-size-1	 (720 126 720 108) (change-frame-size 5)
adjust-frame-size-3	 (720 126 720 108) (752 126 752 108)
xg-frame-resized	 (720 108 720 90) nil
adjust-frame-size-1	 (720 108 720 90) (change-frame-size 5)
adjust-frame-size-3	 (720 108 720 90) (752 108 752 90)
xg-frame-resized	 (720 90 720 72) nil
adjust-frame-size-1	 (720 90 720 72) (change-frame-size 5)
xg-frame-resized	 (720 90 720 54) nil
adjust-frame-size-1	 (720 90 720 54) (change-frame-size 5)
xg-frame-resized	 (720 90 720 36) nil
adjust-frame-size-1	 (720 90 720 36) (change-frame-size 5)
xg-frame-resized	 (720 90 720 18) nil
adjust-frame-size-1	 (720 90 720 18) (change-frame-size 5)

while for a GTK3 build I get

Frame size history of #<frame *scratch* - GNU Emacs at restno 0x2e5e6d0>
xg-frame-resized	 (720 144 720 126) nil
adjust-frame-size-1	 (720 144 720 126) (change-frame-size 5)
adjust-frame-size-3	 (720 144 720 126) (752 144 752 126)
xg-frame-resized	 (720 126 720 108) nil
adjust-frame-size-1	 (720 126 720 108) (change-frame-size 5)
adjust-frame-size-3	 (720 126 720 108) (752 126 752 108)
xg-frame-resized	 (720 108 720 90) nil
adjust-frame-size-1	 (720 108 720 90) (change-frame-size 5)
adjust-frame-size-3	 (720 108 720 90) (752 108 752 90)
xg-frame-resized	 (720 90 720 84) nil
adjust-frame-size-1	 (720 90 720 84) (change-frame-size 5)

As you can see, the initial parts of these traces are the same.  But
when it comes to shrink the frame below a height of 90 pixels, the GTK3
build goes to 84 pixels and stalls there while the GTK2 build continues
to receive sizes down to one line (18 pixels).  Yet in both cases the WM
window shrinks the same way down to one buffer line.

We could dismiss this issue as a bug nobody will care about because in
practice nobody will notice it.  But suppose we wanted to establish some
useful minimum frame size bounds like other applications (Thunderbird,
Firefox) do and pass them to the window manager.  This works fine for
all builds but the GTK3 one.  There, dragging the frame border ceases
again to report the last corresponding values and we get a frame looking
like in the attached shot (this is a split frame with two windows).

The culprit of the GTK3 behavior is Jan Djärv's fix for Bug#8919 which
overrides X11 functions with homemade ones.  Commenting out these
functions fixes the behavior here.  I'm not sure how to proceed though.

Reverting Jan's change might break Emacs for KDE users again although I
doubt it.  A configure option is no option for people who do not build
their Emacsen.  So a Lisp option is probably the only way to go which
means to copy the functions from SetNrmHint.c to emacsgtkfixed.c.  Or
maybe remove the emacsgtkfixed files altogether?  Any ideas?

martin