bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager)

[Pip Cet]

When starting Emacs (GTK build) on an X server which has no window
manager (such as a newly-created Xnest session), setting
`frame-resize-pixelwise' to t followed by a resize operation often has
no effect.

In GNU Emacs 25.0.50.31 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-08-21 on ...
Repository revision: a9d799b5dea1efb9216dc6f985ffc9bdd25d8cba
Windowing system distributor `The X.Org Foundation', version 11.0.11702000
System Description:     Debian GNU/Linux unstable (sid)

Configured using:
 `configure 'CFLAGS=-O0 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: Beginning of history; no preceding item
user-error: End of history; no default available

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind gfilenotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 81307 5982)
 (symbols 48 19076 0)
 (miscs 40 42 86)
 (strings 32 13284 4355)
 (string-bytes 1 377456)
 (vectors 16 11222)
 (vector-slots 8 413750 4157)
 (floats 8 130 19)
 (intervals 56 179 0)
 (buffers 976 11)
 (heap 1024 33363 990))

Steps to reproduce:

Xnest :3 -geometry 877x877+0+0
DISPLAY=:3 emacs -Q --eval "(progn (setq frame-resize-pixelwise t)
(set-frame-parameter (selected-frame) 'fullscreen 'fullboth))"

Expected result:
Emacs frame fills Xnest window precisely.

Actual result:
Emacs frame size differs from Xnest window size. In my case, the
minibuffer/echo area is cut off and there is an area to the right of
the Emacs window that is not used by the Emacs frame.

Analysis:
There are two problems:
(1) x_check_fullscreen (xterm.c) calls XResizeWindow without first
calling x_wm_set_size_hint (gtkutil.c), which would propagate the
`frame-resize-pixelwise' flag to have an effect on GTK/GDK
(2) x_wm_set_size_hint returns without propagating the
`frame-resize-pixelwise' flag when the frame's fullscreen property is
'maximized or 'fullboth.

The first appears to be simple oversight, but the second is
intentional to work around a KWin bug.

Note that despite the name, the GTK version of `x_wm_set_size_hint'
does not rely on the presence of a window manager or indeed
communicate with it.

Fixing the first problem is trivial, but the second problem would
require knowing more about the KWin bug that is being avoided by the
workaround at #14627.