Version: 3.0 (using KDE 3.2.0, Gentoo) Compiler: gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) OS: Linux (i686) release 2.4.23-ck1 how to reproduce: - open a note and type some text - open RMB menu, choose Clear (note will be cleared and popup menu disappears again) - again open RMB menu. This time it will not respond to mouse events, and block the whole desktop. However, it does listen to the keyboard, so pressing ESC will get rid of it.
update: I see the menu block after any edit of the text, be it clearing or typing something.
I can confirm this the exact same behavior for KNotes 3.0, KDE 3.2.0, gcc (GCC) 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7), Linux 2.6.1.
CVS commit by brade: Neither update focus, nor save the notes on menu actions, the latter one has weird consequences that freeze the whole desktop regarding mouse actions. CCMAIL: 74469-done@bugs.kde.org M +11 -8 knote.cpp 1.98 --- kdepim/knotes/knote.cpp #1.97:1.98 @@ -814,8 +814,10 @@ bool KNote::eventFilter( QObject* o, QEv QFocusEvent *fe = static_cast<QFocusEvent *>(ev); if ( fe->reason() != QFocusEvent::Popup && fe->reason() != QFocusEvent::Mouse ) + { updateFocus(); if ( m_editor->isModified() ) saveData(); } + } else if ( ev->type() == QEvent::FocusIn ) updateFocus(); @@ -826,6 +828,7 @@ bool KNote::eventFilter( QObject* o, QEv if ( o == m_editor->viewport() ) { - if ( ev->type() == QEvent::MouseButtonPress ) - if ( m_edit_menu && ((QMouseEvent*)ev)->button() == RightButton ) + if ( m_edit_menu && + ev->type() == QEvent::MouseButtonPress && + ((QMouseEvent*)ev)->button() == RightButton ) { m_edit_menu->popup( QCursor::pos() );