I do not know if this is an KDE oder firefox issue. Also I do not know which component I should report this to. But I have the hope that someone has an idea how to solve this? II have defined a custom shortcut in the KDE system-settings: "Meta+N" with action "/usr/bin/firefox --browser" This opens a new firefox window by pressing the left Windows key together with "n". I am using this since many years and because of working in the area of the web I open many firefox windows each day. Since some weeks (I think it did start already before upgrading from kubuntu 15.10 to 16.04, but I am not quite sure) I have the problem that a freshly opened firefox window behaves like if the alt-key still was pressed. So if I want to type something in the autofocused location bar that e.g. is starting with "e", the "Edit" menu of firefox is opened instead of inserting the "e" into the location bar. I have to press the escape key first, before I can work with the firefox window normally. Reproducible: Sometimes Steps to Reproduce: 1. Define the mentioned custom hotkey in the system-settings 2. Press left windows key + "n". 3. A firefox window opens. 4. type something into the location bar (an URL or a search word, etc.) Actual Results: Sometimes (very often), but not always you cannot type into the location bar. Instead you are opening different menu items or other functionalities like you were holding the alt-key pressed while typing. Expected Results: The typed characters should show up in the location bar.
Oh, an additional information: On my main PC in the office I am running the last LTS kubuntu with KDE4 (IIRC version 14.04). On this PC the problem does not occur. This is the reason why I think it might have to do with KDE5?
kglobalaccel at best. xev -event keyboard -id <firefox window here> | grep state Alt should be 8 (but that can vary) ie. echo $((<state_value> & 0x8)) should print 8, otherwuse FF believes the Alt key is pressed while there's no such indication from the window system. Stupid question: are both FF versions the same gtk or is one Gtk2 and the other Gtk3?
It is difficult to run the xev command on the firefox window without modifying its state. How do I get the window-id? I only know xwininfo for this. Running xev with the window id does not display anything then. But for this I have to change between firefox and konsole, so this might not be the original state anymore. How can I check which gtk version firefox is using? Running ld on the executable does not work: ld /usr/lib/firefox/firefox ld: warning: cannot find entry symbol _start; not setting start address
firefox is a shellscript, calling the actual binary (usually in /usr/lib, /usr/lib/firefox/firefox-bin ?) you can use xdotool to search window IDs or list them all w/ "xwininfo -root -tree" for "offline" inspection, you'll require remote access (ssh), so you can inspect the system w/o altering the state The alternative would be sth. like sleep 20; xev -event keyboard -id `xdotool search -onlyvisible -class firefox` | grep state to program the inspection before causing the situation. (no guarantee that the search will find exactly one window, better check that w/ FF running)
clearly not a KWin issue. But anyway, waiting for the xev output.
Indeed the firefox command is a shell script. If I am not wrong, it does invoke the command /usr/lib/firefox/firefox that I tried to check with "ld". The issue really seems to be not a kwin issue as it did appear once in KDE4 (kubuntu 14.04), too. But more often it happens with the latest KDE in kubuntu 16.04. It is quite difficult to generate the xev output. First the problem with the wrong firefox behaviour does not happen every time. At the moment I cannot reproduce it. I do not know what triggers the problem. Second the xev command is quite difficult to handle. I do not see any keyboard events. Only mouse events are printed. I will try a little bit more, maybe I have to wait until the problems occurs again when seriously working with the system.
This is annoying: Sometimes xev does print keyboard events, sometimes not. Maybe it is connecting to a wrong window? This happens with only one firefox window as well as with multiple firefox windows. This was the command that I have tested with: sleep 2; echo "running"; WINID=`xdotool search -onlyvisible -class firefox| sort|tail -1`; echo $WINID; xev -event keyboard -id $WINID | grep state I was able to reproduce the faulty behaviour two or three times while opening firefox approximately 50 times, but in these cases xev did not work. :(
The keyboard is probably grabbed (and likely by the firefox menu) iew. it's less like alt being pressed but more like firefox immediately activates the menu (despite it's maybe not even visible) could be due to the release event of the meta key? what if you assign the shortcut to "sleep 1; firefox"?
The idea with "sleep 1; firefox" did not help. I have to press ESC after the window opens to be sure I can enter text into the focused location bar.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
The Problem still exists with Kubuntu 18.04 (32bit on one PC and 64bit on another) and KDE backports. firefox 62.0 KDE Plasma 5.12.5 KDE Frameworks 5.47.0 Qt 5.9.5 Kernel 4.15.0-34-generic (32bit) Sometimes it works, sometimes the menu items are triggered instead of typing an URL into the location bar because the "alt" key seems to be held automatically. At the moment I cannot reproduce the behaviour, but sometimes it occurs. If you tell me what additional info you could need, I will try to offer it.
Thanks, I've set this to REPORTED so it won't be auto-closed.
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
The problem still exists with plasma 5.22.5 (kubuntu 21.04). I will test this with kubuntu 21.10 (plasma 5.23) soon, I hope. Maybe it has to do with some other strange behaviour that I can see in firefox and thunderbird: If I press the alt-key once and release it, the two applications behave like I am still holding the alt-key pressed. I have to press the alt-key again to leave this mode. In KDE applications this does not happen. I really have to hold the alt key here to stay in this mode. (The KDE behaviour is what I do expect.)
It seems that the strange alt key behaviour in firefox and thunderbird can be turned off by the about:config option ui.key.menuAccessKeyFocuses by setting this to false (in firefox and in thunderbird). I have (and had before already) configured the firefox and thunderbird menu to be visible all the time. Maybe this makes a difference with the meta hotkey, too? Today I have upgrade to kubuntu 21.10 with plasma 5.23.3 from the backports. I will see if I will still run in the reported initial problem.
It seems that the issue is gone now, either after changing the configuration if firefox and thunderbird or with Operating System: Kubuntu 21.10 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-22-generic (64-bit) Graphics Platform: X11 I guess the firefox / thunderbird configuration was the culpret: I had configured the app menu to always be visible. Normally it is only displayed on alt-key-press. This might be the reason why no one else could reproduce the issue? After changing also the ui.key.menuAccessKeyFocuses setting in the apps as described, the problem seems to have disappeared. Thanks Gert