One fine morning, I have noticed that the Ctrl+T shortcut to create new Tab in firefox no longer works. Same is the case with restoring a closed tab using Ctrl+Shft+T. After few iterations by opening firefox in safe mode, and reinstalling the firefox, I have noticed behavior has not changed.
But the problem is same for a terminal, where Ctrll+shft+T has to create a new Tab, no longer works. I think this is some kind of system wide conflict of shortcuts or some apps are misconfigured. I am unable to figure out the exact reason.
Kindly help to debug and resolve this issue. Thanks.
Some info regarding my system
rahul@rahul-lap:$ uname -a
Linux rahul-lap 5.3.0-29-generic #31-Ubuntu SMP Fri Jan 17 17:27:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
rahul@rahul-lap:$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 19.10
Release: 19.10
Codename: eoan
rahul@rahul-lap:$ cat /etc/os-release
NAME="Ubuntu"
VERSION="19.10 (Eoan Ermine)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 19.10"
VERSION_ID="19.10"
HOME_URL=""
SUPPORT_URL=""
BUG_REPORT_URL=""
PRIVACY_POLICY_URL=""
VERSION_CODENAME=eoan
UBUNTU_CODENAME=eoan
rahul@rahul-lap:$ setxkbmap -query
rules: evdev
model: pc105
layout: us,us
variant: ,3 Answers
I had a similar problem. While this doesn't necessarily fix your problem, this comment does not fit into the comment section and might be helpful anyway.
Running xev and pressing Ctrl-T showed this:
KeyPress event, serial 40, synthetic NO, window 0x9e00001, root 0x160, subw 0x0, time 3445511468, (-677,97), root:(1251,126), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False
FocusOut event, serial 40, synthetic NO, window 0x9e00001, mode NotifyGrab, detail NotifyAncestor
FocusIn event, serial 40, synthetic NO, window 0x9e00001, mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 40, synthetic NO, window 0x0, keys: 2 0 0 0 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
KeyRelease event, serial 40, synthetic NO, window 0x9e00001, root 0x160, subw 0x0, time 3445521451, (-677,97), root:(1251,126), state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: FalseInstead of FocusOut, it should have shown just another KeyPress event. In my case, I had just installed and run qstardict, which apparently uses Ctrl-T for something. Quitting the app fixed Ctrl-T in all apps.
Now, just for the sake of completion, here's one blunt way to proceed if you suspect a different process might be handling the Ctrl-T:
Quit as many applications running as possible. There are other options, but you could use perf to get a list of all running background processes. (Use sudo apt-get install linux-perf to install.) Run sudo perf record -e context-switches -a sleep 2 and press Ctrl-T within 2 seconds. Then you could do sudo perf script | awk '{print $1}' | sort -n | uniq > running_bg_processes_1. Then do another perf record without pressing Ctrl-T and another perf script piping to a different file. Then look at the differences between the file. You may have to do this multiple times. If you see a difference each time, that process could just be your candidate. If you don't see any consistent differences, it seems likely that at least one of the processes listed is the culprit, so you could narrow it further down from there. E.g. you could strace all the remaining processes and see if there's activity exactly right after you press Ctrl-T.
A temporary work around I have found is to run
dconf reset -f /org/gnome/But, if someone could properly guide to debug what might have happened, it would be grateful.
I had a similar problem and the solution was most unexpected. I took a closer look on my keyboard. My daughter was eating cookies the day before while sitting at it. I found that the key 4 was blocked with a crumb. I removed the crumb. Yay, it did the job :) Yes, this is a real story ;)
0
