If there's a server timeout, then a red box appears. After than, I can no longer use ctrl+w; I get a message about how an ambiguous shortcut was detected, and I should reconfigure my shortcuts. However, when I attempt to do so as directed, only one shortcut for ctrl+w exists, so I can't fix the problem. See attached images. Reproducible: Always
Created attachment 78362 [details] Show the timeout and "ambiguous shortcut detected" pop-up.
Created attachment 78363 [details] This shows the shortcut configuration I'm directed to. There is no ambiguity found for ctrl+w.
Thanks for the bug report. Unfortunately, I have no idea what the cause of this problem is. I'm not sure if it will help, but if I could reproduce the problem, I would try to get a backtrace while the message box is shown to see if this tells us what triggers the alleged shortcut conflict. If you are willing to try that, please do the following: 1. Enter 'gdb dolphin' in a terminal. 2. Enter 'run' at the gdb prompt. 3. Reproduce the bug. Do not close the message box. 4. Switch to the terminal, press "Ctrl+Z". 5. Enter "thread apply all backtrace" and attach the output here. Thanks.
I just found out that the problem only occurs if I have multiple tabs open. Otherwise, ctrl+w closes the red error box. The backtrace you requested is below. (gdb) thread apply all backtrace Thread 9 (Thread 0x7fffd68a4700 (LWP 5930)): #0 0x00007ffff7868023 in select () at ../sysdeps/unix/syscall-template.S:82 #1 0x00007ffff36f4012 in QProcessManager::run (this=0x7ffff3a6d520 <processManager()::processManager>) at io/qprocess_unix.cpp:245 #2 0x00007ffff3618b1c in QThreadPrivate::start (arg=0x7ffff3a6d520 <processManager()::processManager>) at thread/qthread_unix.cpp:338 #3 0x00007fffef53be9a in start_thread (arg=0x7fffd68a4700) at pthread_create.c:308 #4 0x00007ffff786ecbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x0000000000000000 in ?? () Thread 3 (Thread 0x7fffd7fff700 (LWP 5915)): #0 0x00007ffff7863303 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007fffef06cd84 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fffef06cea4 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007ffff3743c46 in QEventDispatcherGlib::processEvents (this=0x7fffd00008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #4 0x00007ffff37142ef in QEventLoop::processEvents (this=this@entry=0x7fffd7ffedd0, flags=...) at kernel/qeventloop.cpp:149 #5 0x00007ffff3714578 in QEventLoop::exec (this=0x7fffd7ffedd0, flags=...) at kernel/qeventloop.cpp:204 #6 0x00007ffff3615b40 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:501 #7 0x00007ffff36f49df in QInotifyFileSystemWatcherEngine::run (this=0x8a3ea0) at io/qfilesystemwatcher_inotify.cpp:248 #8 0x00007ffff3618b1c in QThreadPrivate::start (arg=0x8a3ea0) at thread/qthread_unix.cpp:338 #9 0x00007fffef53be9a in start_thread (arg=0x7fffd7fff700) at pthread_create.c:308 #10 0x00007ffff786ecbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x0000000000000000 in ?? () Thread 2 (Thread 0x7fffdd12c700 (LWP 5914)): #0 0x00007ffff7863303 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007fffef06cd84 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fffef06cea4 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007ffff3743c46 in QEventDispatcherGlib::processEvents (this=0x7fffd80008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #4 0x00007ffff37142ef in QEventLoop::processEvents (this=this@entry=0x7fffdd12bdd0, flags=...) at kernel/qeventloop.cpp:149 #5 0x00007ffff3714578 in QEventLoop::exec (this=0x7fffdd12bdd0, flags=...) at kernel/qeventloop.cpp:204 #6 0x00007ffff3615b40 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:501 #7 0x00007ffff36f49df in QInotifyFileSystemWatcherEngine::run (this=0x84ef10) at io/qfilesystemwatcher_inotify.cpp:248 #8 0x00007ffff3618b1c in QThreadPrivate::start (arg=0x84ef10) at thread/qthread_unix.cpp:338 #9 0x00007fffef53be9a in start_thread (arg=0x7fffdd12c700) at pthread_create.c:308 #10 0x00007ffff786ecbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x0000000000000000 in ?? () Thread 1 (Thread 0x7fffe4755780 (LWP 5910)): #0 0x00007ffff7863303 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007fffef06cd84 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fffef06cea4 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007ffff3743c26 in QEventDispatcherGlib::processEvents (this=0x608b10, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #4 0x00007ffff419cc1e in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #5 0x00007ffff37142ef in QEventLoop::processEvents (this=this@entry=0x7fffffffc010, flags=...) at kernel/qeventloop.cpp:149 #6 0x00007ffff3714578 in QEventLoop::exec (this=0x7fffffffc010, flags=...) at kernel/qeventloop.cpp:204 #7 0x00007ffff45b0428 in QDialog::exec (this=0xd36d80) at dialogs/qdialog.cpp:554 #8 0x00007ffff4d724ba in KMessageBox::createKMessageBox (dialog=dialog@entry=0xd36d80, icon=..., text=..., strlist=..., ask=..., ---Type <return> to continue, or q <return> to quit---
Thanks, with multiple tabs I can also reproduce this. It appears that KMessageWidget uses the shortcut "Ctrl+W" for closing, but that shortcut is also used by Dolphin to close the current tab :-( @Aurélien: Is this intentional? And if yes, could we find a way to either disable or change the message widget's shortcut?
Since ctrl+w is the general close-something-but-don't-exit shortcut, it would be fine if ctrl+w first closed the error message and then closed the window -- although I don't know if that would be easy to do.
(In reply to comment #6) > Since ctrl+w is the general close-something-but-don't-exit shortcut, it > would be fine if ctrl+w first closed the error message and then closed the > window -- although I don't know if that would be easy to do. Unfortunately, it's not easy. We have decided to not use a shortcut for "Close the message widget" instead, see https://git.reviewboard.kde.org/r/114686/.
Git commit 209c36d93c8d22276d9e50c8fa4047c5306fc362 by Frank Reininghaus. Committed on 14/01/2014 at 20:28. Pushed by freininghaus into branch 'master'. Do not use a shortcut for the KMessageWidget's "Close" action This fixes the problem that the standard "Close" shortcut Control+W might conflict with, e.g., the "Close Tab" shortcut in Dolphin. FIXED-IN: 4.13.0 REVIEW: 114686 M +4 -0 kdeui/widgets/kmessagewidget.cpp http://commits.kde.org/kdelibs/209c36d93c8d22276d9e50c8fa4047c5306fc362