© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130911155223
Steps to reproduce:
Recently, probably in the upgrade to Thunderbird 24.0, I've found that the front-most, active window often will not receive keystrokes. Instead they are being sent to the background, inactive window. For example, I attempt to reply to an email, and start typing. I see text in the body as expected, then a second after beginning, the text is sent to the main "mail index" window. The front-most window is shown as selected in the pager, while a non-selected window receives the keystrokes. This means that for long periods, I am unable to send and compose emails. In addition, I'm also often mid-sentence when I realise that the characters aren't appearing, and I've done some weird filing/labelling in the mail index window.
I can alt-tab or click between windows, but cannot seem to type into the compose window. Otherwise, clicking does all you expect it to. You can select menus of the window; you can even select text (although it's the "background window" grey instead of the "foreground window" blue).
I tried to make sure that it was not an issue with X/KDE by testing to see what the reported active window was.
$ xwininfo | grep -i 'window id'
xwininfo: Window id: 0x3c001f6 "Inbox - Uni - Mozilla Thunderbird"
$ xwininfo | grep -i 'window id'
xwininfo: Window id: 0x3c0670c "Write: Re: Foo Bar - Unicode (UTF-8)"
$ sleep 1 && xprop -root | grep -E '^_NET_
_NET_ACTIVE_
$ sleep 1 && xprop -root | grep -E '^_NET_
_NET_ACTIVE_
It seems that even when the active window is reported to be the compose window by X, it will still not receive input. I presume that it's Thunderbird hijacking the active window internally.
I've tried starting in safe mode and manually downloading and running Thunderbird from the website (64-bit version), instead of using the version in the repositories. In both cases, I still hit this bug.
I don't see this in any other application, except for Firefox occasionally. It used to be fairly frequent in Firefox starting in a release around February, but appears to have diminished in frequency since then.
I did similar troubleshooting in Firefox for active window using xev, but this is now buggy and doesn't work. First I found window IDs with
xwininfo | grep -i 'window id'
Then, when the bug occurred, I attempted to see if keystrokes were being passed to the active (but non-responsive) window with
xev -id 0x123456 | grep Key
I also did the same for the background window that was actually responding to the keystrokes. It seems that the active (but non-responsive) window was indeed receiving keystrokes, and the other one was not, although it was responding to them. I presume that again, it's Firefox hijacking the active window internally. It's probably easier for me to do more troubleshooting in Thunderbird, since it's more frequent.
I checked bugzilla to see this had already been filed, but found nothing. However, I'm unsure if this is related: https:/
Also, I'm not sure how to work out what core version this regression could have occurred in, so I've just left it unspecified.
Kubuntu 13.04
KDE 4.10.5
Ubuntu bug trackers.
Thunderbird bug here:
https:/
Firefox bug here:
https:/
Actual results:
Keystrokes go to the background, non-active window.
Expected results:
Keystrokes should go to the foreground, active window.