Bug 466897
Summary: | lines disappearing when introducing tabs in maximized window | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mads Kiilerich <mads> | ||||
Component: | gnome-terminal | Assignee: | Behdad Esfahbod <behdad> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | behdad, jistone, mateuscg | ||||
Target Milestone: | --- | Keywords: | Patch | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2009-09-25 03:18:36 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Mads Kiilerich
2008-10-14 12:34:34 UTC
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Same problem with gnome-terminal-2.25.91-1.fc11.i586 in rawhide 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. Humm. Can't reproduce. I still can with gnome-terminal-2.25.91-2.fc11.i586: shift-ctrl-n alt-f10 seq 100 shift-ctrl-t alt-1 - and notice that 98 now is the last number 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
correctly.
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.
I am running with the patch and can confirm that it works. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I've now copied this bug upstream: http://bugzilla.gnome.org/show_bug.cgi?id=588033 This problem still exists on rawhide, and the patch still works to fix it. 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. Fixed upstream. Will be in f12. |