Launchpad has imported 13 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=466897.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2008-10-14T12:34:34+00:00 Mads wrote: 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): gnome-terminal-2.24.0-2.fc10.i386 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/0 ------------------------------------------------------------------------ On 2008-11-26T03:51:30+00:00 Bug wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/1 ------------------------------------------------------------------------ On 2009-02-19T12:24:12+00:00 Mads wrote: Same problem with gnome-terminal-2.25.91-1.fc11.i586 in rawhide Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/2 ------------------------------------------------------------------------ On 2009-03-20T22:43:45+00:00 Josh wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/3 ------------------------------------------------------------------------ On 2009-03-26T04:44:54+00:00 Behdad wrote: Humm. Can't reproduce. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/4 ------------------------------------------------------------------------ On 2009-03-26T09:47:55+00:00 Mads wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/5 ------------------------------------------------------------------------ On 2009-04-15T03:30:08+00:00 Josh wrote: Created attachment 339613 [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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/6 ------------------------------------------------------------------------ On 2009-04-15T22:14:37+00:00 Mads wrote: I am running with the patch and can confirm that it works. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/7 ------------------------------------------------------------------------ On 2009-06-09T09:47:05+00:00 Bug wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/11 ------------------------------------------------------------------------ On 2009-07-08T01:54:39+00:00 Josh wrote: I've now copied this bug upstream: http://bugzilla.gnome.org/show_bug.cgi?id=588033 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/12 ------------------------------------------------------------------------ On 2009-09-07T06:18:08+00:00 Josh wrote: This problem still exists on rawhide, and the patch still works to fix it. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/13 ------------------------------------------------------------------------ On 2009-09-12T14:23:23+00:00 Mateus wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/14 ------------------------------------------------------------------------ On 2009-09-25T03:18:36+00:00 Behdad wrote: Fixed upstream. Will be in f12. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/378361/comments/15 ** Changed in: gnome-terminal (Fedora) Importance: Unknown => Medium ** Bug watch added: GNOME Bug Tracker #588033 https://bugzilla.gnome.org/show_bug.cgi?id=588033 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/378361 Title: Loss of lines when resizing and creating tab Status in gnome-terminal package in Ubuntu: Fix Released Status in gnome-terminal package in Fedora: Fix Released Bug description: Binary package hint: gnome-terminal Steps to reproduce: 1. Open a new terminal. 2. seq 1 500 3. Go full-screen (F11) 4. Make a new tab (Ctrl-Shift-T) 5. Go back to normal (F11) 6. Switch back to the first tab. Expected result: ... 498 499 500 prompt. Actual result: ... 461 462 prompt. Lines 463-500 are lost forever -- they're not in the scrollback buffer, missing from a copy-paste, etc. Full screen is just the most drastic; the problem occurs whenever you increase the terminal size. The critical factor seems to be creating a new tab. This might be the same as https://bugzilla.redhat.com/show_bug.cgi?id=466897 And perhaps https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/172604 was valid after all. ProblemType: Bug Architecture: i386 DistroRelease: Ubuntu 9.04 NonfreeKernelModules: openafs nvidia Package: gnome-terminal 2.26.0-0ubuntu2 ProcEnviron: PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-terminal Uname: Linux 2.6.28-11-generic i686 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/378361/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
