Bug 466897 - lines disappearing when introducing tabs in maximized window
lines disappearing when introducing tabs in maximized window
Product: Fedora
Classification: Fedora
Component: gnome-terminal (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Behdad Esfahbod
Fedora Extras Quality Assurance
: Patch
Depends On:
  Show dependency treegraph
Reported: 2008-10-14 08:34 EDT by Mads Kiilerich
Modified: 2009-09-24 23:18 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-24 23:18:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
[vte] ensure that scroll_delta is always adjusted (3.04 KB, patch)
2009-04-14 23:30 EDT, Josh Stone
no flags Details | Diff

  None (edit)
Description Mads Kiilerich 2008-10-14 08:34:34 EDT
Description of problem:
When tab headers are shown in maximized window then the 2nd and 3rd lines from the bottom are hidden.

Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. start gnome-terminal and maximize
2. run for example "seq 100" and write your name without hitting enter and memorize the topmost and last lines
3. start new tab with shift-ctrl-tab
4. back to tab 1 with alt-1
Actual results:
5. notice how the top and bottom lines have been preserved even though the available area has shrinked - but in the example the lines 99 and 100 have disappeared

Expected results:
The window should threat the introduction of tabs as a resize and scroll the topmost lines out of view.
Comment 1 Bug Zapper 2008-11-25 22:51:30 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
Comment 2 Mads Kiilerich 2009-02-19 07:24:12 EST
Same problem with gnome-terminal-2.25.91-1.fc11.i586 in rawhide
Comment 3 Josh Stone 2009-03-20 18:43:45 EDT
I discovered that this actually happens with ANY event that reduces the number of lines, which makes this a bit nastier.  It doesn't have to be maximized:

1. Start a gnome-terminal with two tabs.
2. Run "seq 100" in both tabs.
3. Resize the window so that it's a few lines shorter.

The active tab will scroll lines off the top, so nothing is lost.  The other tab will permanently lose a few lines from the bottom, as in the initial report.

Also note that the loss doesn't occur until you actually switch to the background tab.  If you resize the window shorter, return it to the original size, and then look at the background tab, then nothing will be lost.
Comment 4 Behdad Esfahbod 2009-03-26 00:44:54 EDT
Humm.  Can't reproduce.
Comment 5 Mads Kiilerich 2009-03-26 05:47:55 EDT
I still can with gnome-terminal-2.25.91-2.fc11.i586:
seq 100
- and notice that 98 now is the last number
Comment 6 Josh Stone 2009-04-14 23:30:08 EDT
Created attachment 339613 [details]
[vte] ensure that scroll_delta is always adjusted

When gnome-terminal's height is reduced, the active tab's terminal gets
a vte_terminal_size_allocate() call, which queues an adjustment to the
scroll_delta based on visible_rows to ensure that the scrollback moves

However, when you then switch to a different tab, that terminal gets a
vte_terminal_set_size() first, which will update terminal->row_count
with the new height.  Only after it's visible does it get
vte_terminal_size_allocate(), and there the computation of visible_rows
thinks that there's no reduction (since terminal->row_count already
matches the new height), so it doesn't compute the new scroll_delta.

This patch moves the scroll_delta computation into set_size so it is
always kept current.
Comment 7 Mads Kiilerich 2009-04-15 18:14:37 EDT
I am running with the patch and can confirm that it works.
Comment 8 Bug Zapper 2009-06-09 05:47:05 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 9 Josh Stone 2009-07-07 21:54:39 EDT
I've now copied this bug upstream:
Comment 10 Josh Stone 2009-09-07 02:18:08 EDT
This problem still exists on rawhide, and the patch still works to fix it.
Comment 11 Mateus César Gröess 2009-09-12 10:23:23 EDT
Behdad, do you still can't reproduce the problem? I just saw Gnome 2.28 Release Planning and noticed the Hard Code Freeze is entering September 14.
Comment 12 Behdad Esfahbod 2009-09-24 23:18:36 EDT
Fixed upstream.  Will be in f12.

Note You need to log in before you can comment on or make changes to this bug.