Bug 217592

It's a Qt 4.6 bug (one of many - the buggiest Qt I remember in years and years).

Can't reproduce it with KDE 4.3.4 and Konversation from SVN

Notably it doesn't happen consistently, just intermittently. Started with 4.6rc1 :-(.

Anyone knows if this was fixed upstream ?

It's still happening in Qt 4.7 Technical Preview 1 at least.

SVN commit 1125863 by smartins:


Workaround the disappearing mouse cursor bug so we can use to-do view without having to restart korganizer.

CCBUG: 231177
CCBUG: 217592

MERGE: none



 M  +3 -0      kotodoviewquickaddline.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1125863

*** Bug 231177 has been marked as a duplicate of this bug. ***

*** Bug 244128 has been marked as a duplicate of this bug. ***

There's been a small breakthrough: A user has finally found a reliable way to reproduce the problem (though for him, as for some others, the cursor changes into the text cursor instead of disappearing entirely).

1. Make sure you have the large paste warning dialog enabled (it is by default)
2. Select several lines of text in the chat text view
3. Try pasting them into the input line using middle-mouse (not Ctrl+V)
4. Close the large paste warning dialog that appears using the ESC key (this cancels the paste)
5. Cursor is now screwed up above the tab bar/tab list

Armed with the above and the knowledge that the Qt bug was so far as we remember introduced some time between Qt 4.6beta and Qt 4.6rc1, someone could bisect Qt to find the offending revision.

Some months ago i bisected the korganizer "disappearing cursor" bug down to Qt 4.5 and gave up, was still reproducible.

I then noted that creating a QDialog instead of a KDialog made the bug go away, so i trimmed KDialog until it was ok, and that led to KDE's r989720.

That commit introduced the bug (or exposed a Qt bug).

Let me amend the above steps to reproduce a bit:

1. Make sure you have the large paste warning dialog enabled (it is by default)
2. Select several lines of text in the chat text view
3. Place the mouse cursor in the input line
4. Type several characters - this causes the mouse cursor to disappear, due to KDE's hide-cursor-when-typing feature
5. Paste the previously selected lines into the input line using middle-mouse (not Ctrl+V) without causing the cursor to move so much that it is unhidden in the process
6. Close the large paste warning dialog that appears using the ESC key (this
cancels the paste)
5. Cursor is now screwed up above the tab bar/tab list

*** Bug 247284 has been marked as a duplicate of this bug. ***

I tried Sergio's suggestion: reverting KDialog to r989719.
Unfortunately this did not make the bug go away in konversation.

Note: I reproduced the bug with the steps from Eike (from #c11).
I built konversation from git just a few hours ago (d2c114f67f6db1f0eae7edecdaf0486ca317970a was the last commit).

First I tried to revert the changes from r989720 (and just those changes):
=> bug still occurred.
Then I tried to revert to r989720-1 (=r989719):
=> bug still occurred.

Thank you Martin. That's unfortunately what I feared; the old and new KDialog code should be functionally equivalent. The hunt continues ...

commit 0a5bc983c817c24783b9578b0ed236bc3a9c3645
Author: Eike Hein <hein@kde.org>
Date:   Mon Sep 20 12:35:44 2010 +0200

    Work around bug 217592 (the infamous cursor disappearing act).
    
    The underlying ongoings are that there are two widgets involved,
    the KTextEdit and it's viewport(), both of which KCursor installs
    an event filter on, which on keypress events sets a blank cursor
    on the KTextEdit. On a FocusOut event, such as occurs when the
    paste warning KMessageBox is spawned and assumes focus, KCursor
    then calls unsetCursor() on it. Qt's behavior however seems to
    have changed in such a way that unsetCursor() doesn't affect the
    KTextEdit's viewport(), which QTextEdit originally set the I-Beam
    cursor on. So we do it manually here. But in the end either the
    Qt behavioral change has to be addressed, or KCursor has to be
    equipped to deal with it, since this obviously can happen in all
    KDE apps (and does, as seen in bug 231177).
    CCBUG:217592

diff --git a/src/viewer/ircinput.cpp b/src/viewer/ircinput.cpp
index 05653a8..a282e63 100644
--- a/src/viewer/ircinput.cpp
+++ b/src/viewer/ircinput.cpp
@@ -501,6 +501,9 @@ bool IRCInput::checkPaste(QString& text)
         QString bytesString = i18np("1 byte", "%1 bytes", text.length());
         QString linesString = i18np("1 line", "%1 lines", lines+1);
 
+        // Work around bug 217592.
+        viewport()->setCursor(Qt::IBeamCursor);
+
         doPaste=KMessageBox::warningYesNoCancel
             (this,
             i18nc(

Upstream (Qt) bug report with test case: http://bugreports.qt.nokia.com/browse/QTBUG-6185

The Qt bug has been fixed now and the fix will hopefully be included in Qt 4.7.1.

*** Bug 271880 has been marked as a duplicate of this bug. ***