Bug 236733

Summary: scrolls to bottom when window becomes active again
Product: [Applications] konsole Reporter: Ansgar <ansgar>
Component: generalAssignee: Konsole Developer <konsole-devel>
Severity: normal CC: adaptee, blackdeagle89, myk002, simonandric5
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In: 4.8

Description Ansgar 2010-05-07 18:57:10 UTC
Version:            (using KDE 4.4.3)
OS:                Linux
Installed from:    Debian testing/unstable Packages

When scrolling up, then switching to another window and finally going back to Konsole by clicking somewhere in the window, Konsole scrolls all the way down.  This has changed in 4.4.x (I was using 4.3.4 before).

It is very inconvinient as I often look at some log in the scrollback, copy&paste things from there and then want to continue looking at the log.  Having to scroll back by hand all the time makes this much more time-consuming.
Comment 1 Christoph Feck 2010-05-11 00:20:26 UTC
I cannot reproduce on trunk. Neither Alt+Tab, nor clicking on the title bar or into the window makes it scroll down.
Comment 2 Ansgar 2010-08-24 14:55:27 UTC
I still have this problem with KDE 4.4.5 from Debian unstable/testing.

But there is an additional condition to reproduce it:
Konsole only scrolls down when switching back the focus from another Konsole window (switching back from an Emacs window does not cause this behavior).  It only happens when clicking in the main window, but also when doing so after switching back the focus using Alt-Tab or clicking on the title bar.
Comment 3 Myk Taylor 2011-03-08 09:55:27 UTC
This is bugging me as well in kde-4.6.1.

Here's an easy way to reproduce:
1) open up a konsole window and open two tabs in the window
2) hit enter enough times to make the window scrollable
3) start a command that outputs intermittently:
     while true; do sleep 5; echo "should not scroll"; done
4) scroll up a few lines so that the new output is below the current screen
5) switch to the other tab (shift left)
6) wait for the tab that's running the command to become highlighted, indicating activity
7) switch back to that tab (shift right).  the next time you click on the screen (say to highlight some text) or new output is written, the scrollbar will jump to the bottom.
Comment 4 Soner K. 2011-03-23 09:22:57 UTC
Sorry, I cannot reproduce your problem by following the steps!

I did ls and ls -l so often that konsole was scrollable. Then I switched to another tab in konsole after typing in the thing with the while-loop. I scrolled up and switched to another tab and waited until the tab with the while-loop was highlighted (indicating activity). 
I changed back to the tab with the while-loop, it was still scrolled up. I could click and highlight text without having it scrolled down!

I'm using KDE 4.6.1 and Konsole 2.6.1
Additionally I use zsh as the command shell.
Comment 5 Myk Taylor 2011-03-23 18:04:57 UTC
interesting.  I installed zsh just to be sure we're testing under the same conditions, and I was still able to reproduce the problem.  What else could be different?  I'm on Gentoo x86_64, I use the binary NVidia drivers, desktop effects are on.  xorg-x11-7.4 (xorg-server-1.9.4, xf86-input-mouse-1.6.0).  I'm not sure which variables are relevant here, though...

It may not have anything to do with the mouse, though, since the window scrolls to the bottom even without a mouse click -- just wait 5 seconds for the next line of output and it will scroll down without any interaction.
Comment 6 Myk Taylor 2011-05-05 02:57:03 UTC
Hrm, perhaps it is relevant that I am using ibus-1.3.9 and ibus-qt-1.3.0 for internationalized input?  I have the following variables set system-wide:

Comment 7 Jekyll Wu 2011-08-06 14:58:14 UTC
I can reproduce this problem as instructed in comment #2 and #4 in konsole 2.7.

The important condition is the focus is previously in the same konsole process , but in another main window, or another tab.

I am using zsh, ibus and ibus-qt, and the environment is the same as in comment #6
Comment 8 Jekyll Wu 2011-08-06 18:06:06 UTC
If ibus is not running, this problem does not exist. 

After some investigation, I got a clue:

1). If ibus is running(even not activated), when focus is switched from one tab to another tab through mouse or keyboard, TerminalDisplay::inputMethodEvent() will always be triggered, which in turn emits the keyPressedSignal .

2). That will make konsole believe some key has been pressed, so it scrolls to to bottom.
Comment 9 Jekyll Wu 2011-08-15 04:34:24 UTC
Git commit caece88d2c5b5b6f0da3dc048878831814aab9f3 by Jekyll Wu.
Committed on 15/08/2011 at 06:31.
Pushed by jekyllwu into branch 'master'.

Don't emit keyPressedSignal when QInputMethodEvent::commitString() is empty.

When user switches focus (even using mouse) between tabs/windows
of konsole, ibus will trigger inputMethodEvent(). Most of the time
commitString() will be empty. Do not emit keyPressedSignal in such case,
otherwise konsole will scroll active view to bottom. See bug #236733.

The side effect is when inputmethod is activated, the active view
will not scroll to bottom on keystroke until user has committed
some string.

BUG: 236733
REVIEW: 102238
FIXED-IN : 4.8

M  +5    -2    src/TerminalDisplay.cpp