bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

[charlie hemlock]

> The Motif frame looks better, but still not entirely normal: what's that empty space to the right of the  window? Is that similar  to what you see locally on the GNU/Linux box?

That empty narrow space looks similar as locally launched Emacs. That narrow area is where line wrap indicators show up.

> If "C-x C-c" works, then does  "M-x redraw-display RET" redraw the frame to its normal appearance?

No.

> What about "C-x 5 b  RET" -- does it create a new frame, and does that frame look correctly?

Creates new frame. Does not look correct - same as first.

C-x 2   does split frame. But still missing minibuffer and can't type in either buffer.

I also clicked the "File" button on menu bar, and got several errors below, and the File Menu did not display:
However, Clicking the Open File icon did open the file browser .

Related to this menu issue:
 - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
 - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319

 - Can't say if these are related to the original display issues discussed here or entire separate issue

% ~/release/emacs_26.1/bin/emacs -Q

(emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

[[removed several repeats]]

(emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

(emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget (node arrow, owner GtkMenu)

(emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget (node arrow, owner GtkMenu)
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

(emacs:3612): Gtk-WARNING **: Negative content width -11 (allocation 1, extents 6x6) while allocating gadget (node menuitem, owner GtkMenuItem)

(emacs:3612): Gtk-WARNING **: Negative content height -7 (allocation 1, extents 4x4) while allocating gadget (node menuitem, owner GtkMenuItem)

[[removed several repeats]]

In my original post - I forgot to mention with xming 6.9.0.31 (not vcxsrv) I get different emacs behavior (the test combinations are growing) .

The emacs gui launches and appears ok, but core dumps as soon as I attempt anything else.
% ~/release/emacs_26.1/bin/emacs -Q

# click anywhere

X protocol error: BadRequest (invalid request code or no such operation) on protocol request 130
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.
Fatal error 6: Aborted

But I did include that bug link in original post.   I can't say if these are closely or distantly or not related.

Anyone else experiencing or able to replicate?

Thanks!

On Mon, Apr 16, 2018 at 10:34 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> From: charlie hemlock <charliehemlock@gmail.com>
> Date: Mon, 16 Apr 2018 19:37:44 -0400
> Cc: 31169@debbugs.gnu.org
>
> > Is this all you see in the Emacs frame?  It looks like a part of a
> > frame , did you clip the image, perhaps?  If so, please show all of the frame.
>
> That was all the frame. Including new attachment [emacs26_gtk3.png] for clarity. (show a little of background
> and putty window). I tried resizing window and same result.
>
> > To make sure this is related to GTK, could you try building with a
> > different toolkit, just to see if that build starts as expected?
>
> Attached with "motif" x-toolkit screenshot. [emacs26_motif.png].
> Appears OK,  but I can't ./configure --with-xwidgets

The Motif frame looks better, but still not entirely normal: what's
that empty space to the right of the window?

Is that similar to what you see locally on the GNU/Linux box?

>   > Does it eat CPU cycles? 
> No - just looked a 'top' output.
>
> > Can you exit it with "C-x C-c" or do you have to kill it by a
> signal? 
> C-x C-x works.

If "C-x C-c" works, then does "M-x redraw-display RET" redraw the
frame to its normal appearance?

What about "C-x 5 b RET" -- does it create a new frame, and does that
frame look correctly?

Thanks.