Bug 317306

Summary:	"Close current tab" and "Close the message widget" share the same shortcut (Ctrl+W)
Product:	[Applications] dolphin	Reporter:	Leon Maurer <leon.maurer>
Component:	general	Assignee:	Dolphin Bug Assignee <dolphin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	agateau
Priority:	NOR
Version:	2.2
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	http://commits.kde.org/kdelibs/209c36d93c8d22276d9e50c8fa4047c5306fc362	Version Fixed In:	4.13.0
Sentry Crash Report:
Attachments:	Show the timeout and "ambiguous shortcut detected" pop-up. This shows the shortcut configuration I'm directed to. There is no ambiguity found for ctrl+w.

Description Leon Maurer 2013-03-25 03:09:55 UTC

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

Comment 1 Leon Maurer 2013-03-25 03:10:37 UTC

Created attachment 78362 [details]
Show the timeout and "ambiguous shortcut detected" pop-up.

Comment 2 Leon Maurer 2013-03-25 03:11:49 UTC

Created attachment 78363 [details]
This shows the shortcut configuration I'm directed to. There is no ambiguity found for ctrl+w.

Comment 3 Frank Reininghaus 2013-03-25 09:59:29 UTC

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.

Comment 4 Leon Maurer 2013-03-25 13:21:33 UTC

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---

Comment 5 Frank Reininghaus 2013-03-25 15:00:48 UTC

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?

Comment 6 Leon Maurer 2013-03-25 15:39:57 UTC

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.

Comment 7 Frank Reininghaus 2014-01-14 20:28:22 UTC

(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/.

Comment 8 Frank Reininghaus 2014-01-14 20:30:46 UTC

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