After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 750559 - Startup size one cell smaller than configuration
Startup size one cell smaller than configuration
Status: RESOLVED OBSOLETE
Product: gnome-terminal
Classification: Core
Component: general
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-06-08 12:10 UTC by Tony Houghton
Modified: 2017-10-21 17:18 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tony Houghton 2015-06-08 12:10:35 UTC
When opening a new terminal its size is one column and one row smaller than the configured settings, as reported by $COLUMNS and $LINES and when starting to drag a window border. For example, by default it's 79x24 instead of 80x25.

This happens with GNOME 3 and Adwaita in Debian. I haven't tried other themes and environments.

It's probably caused by failing to take some border/margin sizes into account correctly. After updating roxterm for vte-2.91 I had a similar bug because I'd had to remove code that read sizes from obsolete vte properties. I replaced it with this for a successful fix:

    GtkBorder border;
    GtkStateFlags state = gtk_widget_get_state_flags(roxterm->widget);
    gtk_style_context_get_padding(roxterm->style_context,
            state, &border);
    roxterm->padding_w = border.left + border.right;
    roxterm->padding_h = border.top + border.bottom;
    gtk_style_context_get_border(roxterm->style_context,
            state, &border);
    roxterm->padding_w += border.left + border.right;
    roxterm->padding_h += border.top + border.bottom;
    gtk_style_context_get_margin(roxterm->style_context,
            state, &border);
    roxterm->padding_w += border.left + border.right;
    roxterm->padding_h += border.top + border.bottom;
Comment 1 Christian Persch 2015-06-08 16:03:35 UTC
Not reproducible here with gtk+, vte and g-t from git master.
Comment 2 Debarshi Ray 2015-06-09 19:27:10 UTC
Can't reproduce with 3.14 (Fedora 21) and 3.16 (Fedora 22) either. Although, I do recall a similar issue in the past that we fixed. Don't remember the details off hand.
Comment 3 Ian Abbott 2015-07-03 12:15:15 UTC
I also have this problem in Debian stretch ("testing") (I'm also using GNOME 3 and Adwaita).

There are also a some related bugs for Ubuntu:

https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1043908
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1290941
Comment 4 Christian Persch 2015-07-14 17:51:04 UTC
https://bugs.debian.org/787104 says the same happens in debian and the problem appears with the upgrade from 3.14.1-1 to 3.14.2-1 (and downgrade fixes it again). The problem is that there are no upstream changes in src/ at all between 3.14.1 and .2, nor does debian add any patches that might impact this...
Comment 5 Ian Abbott 2015-07-15 10:16:52 UTC
I've built the gnome-3-16 git branch of gnome-terminal on Debian stretch and it behaves the same way (new terminals end up as e.g. 79x23 instead of 80x24).  I've also built a slightly modified "master" with commit ba2ef8e000e2 ("notebook: Add pref to always show tabs bar") reverted, and that behaved the same way.  (I had to revert that commit as I didn't overwrite the "org.gnome.Terminal.gschema.xml"  in my system for this test, and the system installed version didn't have the 'tab-policy' key, causing gnome-terminal-server to bail out.)

I didn't build anything else for these tests - I just used the libraries installed by Debian stretch.

Here are my libs for gnome-terminal-server:

/lib64/ld-linux-x86-64.so.2
libX11.so.6
libXau.so.6
libXcomposite.so.1
libXcursor.so.1
libXdamage.so.1
libXdmcp.so.6
libXext.so.6
libXfixes.so.3
libXi.so.6
libXinerama.so.1
libXrandr.so.2
libXrender.so.1
libatk-1.0.so.0
libatk-bridge-2.0.so.0
libatspi.so.0
libc.so.6
libcairo-gobject.so.2
libcairo.so.2
libdatrie.so.1
libdbus-1.so.3
libdconf.so.1
libdl.so.2
libepoxy.so.0
libexpat.so.1
libffi.so.6
libfontconfig.so.1
libfreetype.so.6
libgdk-3.so.0
libgdk_pixbuf-2.0.so.0
libgio-2.0.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgmp.so.10
libgnutls-deb0.so.28
libgobject-2.0.so.0
libgraphite2.so.3
libgthread-2.0.so.0
libgtk-3.so.0
libharfbuzz.so.0
libhogweed.so.4
libm.so.6
libnettle.so.6
libp11-kit.so.0
libpango-1.0.so.0
libpangocairo-1.0.so.0
libpangoft2-1.0.so.0
libpcre.so.3
libpixman-1.so.0
libpng12.so.0
libpthread.so.0
libresolv.so.2
librt.so.1
libselinux.so.1
libtasn1.so.6
libthai.so.0
libutil.so.1
libuuid.so.1
libvte-2.91.so.0
libwayland-client.so.0
libwayland-cursor.so.0
libwayland-egl.so.1
libxcb-render.so.0
libxcb-shm.so.0
libxcb.so.1
libxkbcommon.so.0
libz.so.1
linux-vdso.so.1

And here are my libs for gnome-terminal:

/lib64/ld-linux-x86-64.so.2
libX11.so.6
libXau.so.6
libXcomposite.so.1
libXcursor.so.1
libXdamage.so.1
libXdmcp.so.6
libXext.so.6
libXfixes.so.3
libXi.so.6
libXinerama.so.1
libXrandr.so.2
libXrender.so.1
libatk-1.0.so.0
libatk-bridge-2.0.so.0
libatspi.so.0
libc.so.6
libcairo-gobject.so.2
libcairo.so.2
libdatrie.so.1
libdbus-1.so.3
libdconf.so.1
libdl.so.2
libepoxy.so.0
libexpat.so.1
libffi.so.6
libfontconfig.so.1
libfreetype.so.6
libgdk-3.so.0
libgdk_pixbuf-2.0.so.0
libgio-2.0.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgmp.so.10
libgnutls-deb0.so.28
libgobject-2.0.so.0
libgraphite2.so.3
libgthread-2.0.so.0
libgtk-3.so.0
libharfbuzz.so.0
libhogweed.so.4
libm.so.6
libnettle.so.6
libp11-kit.so.0
libpango-1.0.so.0
libpangocairo-1.0.so.0
libpangoft2-1.0.so.0
libpcre.so.3
libpixman-1.so.0
libpng12.so.0
libpthread.so.0
libresolv.so.2
librt.so.1
libselinux.so.1
libtasn1.so.6
libthai.so.0
libutil.so.1
libuuid.so.1
libvte-2.91.so.0
libwayland-client.so.0
libwayland-cursor.so.0
libwayland-egl.so.1
libxcb-render.so.0
libxcb-shm.so.0
libxcb.so.1
libxkbcommon.so.0
libz.so.1
linux-vdso.so.1

I have an Arch Linux system at home I can try testing, but I haven't got around to it yet!
Comment 6 Ian Abbott 2015-07-15 15:16:13 UTC
I've done a bit of debugging of the gnome-3-16 branch of gnome-terminal on my Debian stretch system.

I set a breakpoint on the end of terminal_screen_get_size() so I could print the results of the calls to vte_terminal_get_column_count() and vte_terminal_get_row_count().  I also set a breakpoint on vte_terminal_set_size(), but was unable to determine the parameters it was called with as Debian does not provide a "dbg" package for its libvte-2.91-0.

The first two calls to terminal_screen_get_size() pick up the correct columns and rows.  The third call picks up incorrect columns and rows.  There is a call to vte_terminal_set_size() between the 2nd and 3rd calls to terminal_screen_get_size().  The sequence of breakpoint hits is as follows:

(Line numbers are valid as of commit 96f5cfe00550 on branch gnome-3-16.)

(HIT-1) vte_terminal_set_size() called as a result of this line in terminal_screen_new() [terminal-screen.c:619]:

  screen = g_object_new (TERMINAL_TYPE_SCREEN, NULL);

, called directly from terminal_factory_impl_create_instance() [terminal-gdbus.c:462], as a result of this line in _terminal_factory_skeleton_handle_method_call() [terminal-gdbus-generated.c:857]:

  g_signal_emitv (paramv, signal_id, 0, &return_value);

, as a result of this line in main() [server.c:173]:

  return g_application_run (app, 0, NULL);

(HIT-2) vte_terminal_set_size() called directly from terminal_screen_new() [terminal-screen.c:623] {same call of terminal_screen_new() as HIT-1}.

(HIT-3) terminal_screen_get_size() called directly from terminal_window_update_size() [terminal-window.c:3153], directly from mdi_screen_switched_cb() [terminal-window.c:3290], as a result of this line in terminal_notebook_switch_page() [terminal-notebook.c:273]:

  g_signal_emit_by_name (notebook, "screen-switched", old_active_screen, screen);

, as a result of this line in terminal_notebook_add_screen() [terminal-notebook.c:103]:

  gtk_notebook_insert_page (gtk_notebook,
                            screen_container,
                            tab_label,
                            position);
 
, as a result of this line in terminal_factory_impl_create_instance() [terminal-gdbus.c:464]:

  terminal_window_add_screen (window, screen, -1);

{same call of terminal_factory_impl_create_instance() as HIT-1}.

(HIT-4) terminal_screen_get_size() called directly from terminal_window_update_size() [terminal-window.c:3153], directly from terminal_window_show() [terminal-window.c:2889], as a result of this line in terminal_factory_impl_create_instance() [terminal-gdbus.c:502]:

    gtk_window_present (GTK_WINDOW (window));

{same call of terminal_factory_impl_create_instance() as HIT-1}.

(HIT-5) vte_terminal_set_size() called as a result of this line in terminal_window_show() [terminal-window.c:2892]:

  GTK_WIDGET_CLASS (terminal_window_parent_class)->show (widget);

{same call of terminal_window_show() as in HIT-4}.

(HIT-6) terminal_screen_get_size() called directly from terminal_window_update_size() [terminal-window.c:3153], as a result of a chain of function calls in libgobject-2.0, libgtk-3, libgdk-3, libglib-2.0, and libgio-2.0 leading back to main() [server.c:173]


It's going wrong somewhere between HIT-4 and HIT-6.
Comment 7 Ian Abbott 2015-07-15 15:39:31 UTC
I've done some more testing on my Debian stretch system by building the vte-0-40 branch of vte (commit 776b71331c21) configured as follows:

CFLAGS="-O2 -g" ./configure --disable-introspection --disable-vala --enable-maintainer-mode

After building, I ran the Debian-installed gnome-terminal-server as follows:

LD_LIBRARY_PATH=/path/to/my/vte/src/.libs /usr/lib/gnome-terminal/gnome-terminal-server --app-id my.foo.Terminal

and from another terminal session ran the Debian-installed gnome-terminal as

/usr/bin/gnome-terminal --app-id my.foo.Terminal

This created a new gnome-terminal window with the correct number of rows and columns. Spawning new terminal windows from that one via CTRL-SHIFT-N also produced terminal windows with the correct number of rows and columns.

So it looks like the problem lies somewhere in Debian's libvte-2.91-0 package (version 0.40.2-1), but I have yet to determine whether it has been fixed by some commit, or whether it is due to my configure options or compiler flags.
Comment 8 Ian Abbott 2015-07-15 16:41:12 UTC
I've done some more testing and the bug seems to be the result of a Debian patch.

I built Debian's vte2.91_0.40.2.orig.tar.xz configured as follows:

./configure --disable-introspection --disable-vala --enable-maintainer-mode

After building, I ran gnome-terminal-server as follows:

LD_LIBRARY_PATH=/path/to/debian/vte-0.40.2/src/.libs /usr/lib/gnome-terminal/gnome-terminal-server --app-id my.foo.Terminal

and from another terminal ran gnome-terminal as:

/usr/bin/gnome-terminal --app-id my.foo.Terminal

The new terminal window was launched with the correct number of columns and rows, as did new terminals spawned via CTRL-SHIFT-N.

I then applied Debian's patch series from their vte2.91_0.40.2-1.debian.tar.xz and rebuilt and retested.  This time, the new terminal windows were launched with the wrong number of columns and rows (shrunk by one character in each direction).

I narrowed it down to the patch "debian/patches/0001-Add-the-style-context-provider-with-FALLBACK-priorit.patch" which matches commit a264918ad22973c69897c559260e77cb14018235 ("Add the style context provider with FALLBACK priority") on vte's master branch.
Comment 9 Christian Persch 2015-07-15 16:55:36 UTC
Thanks for tracking this down! I reverted the vte commit.
Comment 10 Tony Houghton 2015-07-15 17:42:13 UTC
I don't think it's a problem with vte alone, because I haven't had this problem with roxterm. I suspect the patch changes the amount of padding or something and gnome-terminal isn't taking that padding into account correctly.
Comment 11 Michael Biebl 2015-07-15 19:17:43 UTC
q(In reply to Tony Houghton from comment #10)
> I don't think it's a problem with vte alone, because I haven't had this
> problem with roxterm. I suspect the patch changes the amount of padding or
> something and gnome-terminal isn't taking that padding into account
> correctly.

roxterm in Debian doesn't use vte2.91_0.40.2-1, so it can't be affected by this.
Comment 12 Tony Houghton 2015-07-15 22:21:23 UTC
roxterm 3.0.2 is in a queue pending release and I've been using pre-releases built against vte2.91 in Debian for several weeks.
Comment 13 Iain Lane 2015-07-16 09:48:53 UTC
Can people who were able to reproduce reliably (I couldn't...) try the new patch on bug #740123?
Comment 14 Ian Abbott 2015-07-16 10:11:55 UTC
(In reply to Tony Houghton from comment #10)
> I don't think it's a problem with vte alone, because I haven't had this
> problem with roxterm. I suspect the patch changes the amount of padding or
> something and gnome-terminal isn't taking that padding into account
> correctly.

Slightly more curious is that occasionally the very first gnome-terminal window associated with the gnome-terminal-server gets created at the correct size, although all subsequent windows associated with the server get created at the wrong size.  (I'm talking about gnome-terminal using Debian's modified vte-0.40.2 here.)  So maybe there is a race condition.

The same problem occurs when (at least Debian's) gnome-terminal-server is linked to git master vte before the style context provider patch was reverted, so reverting it was the correct thing to do until a better replacement is found.

(I'll give Iain Lane's replacement patch on bug #740123 a try.)
Comment 15 Ian Abbott 2015-07-16 12:48:00 UTC
I'm guessing the original problem is related to the fact that changing the GNOME Theme on the fly can make the terminal smaller (I'm not sure if that's to be considered a bug or not), and that when the terminal window is created, the theme settings kick in sometime after the the initial terminal size has been set and that results in the terminal size being changed.

With Iain Lane's replacement patch on bug #740123 attachment #307535 [details], on the fly changes to the theme no longer reduced the number of columns, but could still reduce the number of rows (at least when switching between the Adwaita, Albatross, Blackbird, Bluebird, and Greybird themes).
Comment 16 Tony Houghton 2015-11-16 23:25:32 UTC
The "geometry issues" in <https://github.com/mate-desktop/mate-terminal/issues/66> look as if they might be related to this.
Comment 17 Anders Kaseorg 2015-12-23 02:03:37 UTC
(In reply to Iain Lane from comment #13)
> Can people who were able to reproduce reliably (I couldn't...) try the new
> patch on bug #740123?

I have this problem on Ubuntu Gnome, which still includes the old version of the patch.  Replacing it with the new version of the patch fixes it for me.
Comment 18 Christian Persch 2017-10-21 17:18:02 UTC
Please re-test this with vte 0.50.latest / git master; there's been some padding related fixes recently. Re-open if it's still reproducible using vte master.