Similarly to my problems with Firefox, I'm now seeing keystrokes sent to the inactive window in Thunderbird 24.0.

This happens intermittently, but for at least 10 minutes just then, it occurred a dozen times in a row with the following: Find a message. Attempt to reply with ctrl+r. Start typing. This makes it almost impossible to email anyone! However, when I just went back to check it, it had suddenly fixed itself.

When this bug occurs, keystrokes go to the original "mail index" window. I can click on the front "reply" window, but I cannot activate it to type in. 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've attempted to troubleshoot a bit, but it seems that the same instructions from the original thread don't work any more.

luebking wrote:1. obtain the WId of the window that should receive the keystrokes. (run "xwininfo | grep -i 'window id'" and look for the hex number like 0x123456)
2. run ["xev -id 0x123456 | grep Key"] where "0x123456" should be the actual WId from (1)
3. ensure you get ouput from this while the window works as expected.
4. watch for the output when the window starts to misbehave.

In this case, I get no output when typing, whether the window was behaving or not. I tried `xev -id 0x123456` without the grep, but there was so much noise it was hard to tell what was happening.

Firefox and Thundebird are virtually the same application (at least in this regard) ....

-> Does the mainwindow get the Key events all the time, ie. even while the editor window is "behaving"?

I suspect inteference with the focus stealing protection here - try setting it to "none".
If the issue never re-occurs then, add a resp. rule for the TB editor window.

Also please record the outputs of "xwininfo" and "xprop" on both, the mainwindow as well as the editor.

Thanks for the comments.

luebking wrote:-> Does the mainwindow get the Key events all the time, ie. even while the editor window is "behaving"?

As I mentioned in the OP, if you are referring to (2) in the quote, I can't seem to get it to work in Thunderbird.

luebking wrote:I suspect inteference with the focus stealing protection here - try setting it to "none".
If the issue never re-occurs then, add a resp. rule for the TB editor window.

Also please record the outputs of "xwininfo" and "xprop" on both, the mainwindow as well as the editor.

Thanks, I've set it up, and see if it makes a difference. FWIW I had focus stealing prevention set to "low" before. I'll get xwininfo and xprop if it occurs again.

Also, I guess it's related, but I find very focus stealing to be very intermittent. I use RSSOwl to read feed, and frequently follow links, which are opened in Firefox. Some of the time, Firefox (in another virtual desktop) jumps to the front, and some of the time focus stays with RSSOwl. What's strange is that even after changing focus stealing prevention to "off", I just had a case where Firefox did not jump to the front.

I just had the same bug again in Firefox, after changing focus stealing prevention to none. To clarify, the front-most window is shown as selected in the KDE pager, while a non-selected Firefox window receives the keystrokes. Again, as in Thunderbird, I could select text in the windows, but the window that looked to be front-most but wasn't receiving input had its text selected in the "background" grey, whereas the other window that stole all input had text shaded in the "foreground" blue. This occurred no matted which was front-most and selected in the KDE pager.

I tried xwininfo and xprop for the two windows. For xwininfo, nothing differed apart from title and geometry. Here they are for the thieving window (i.e. the one stealing input) and for the victim (i.e. the window that won't receive input).

I didn't totally understand the differences in xprop, so here it is for thief and victim.

Again, `xev -id 0x123456 | grep Key` failed. I get nothing on keypresses, even on a working window, but only the following when the mouse cursor enters the window

Code: Select all

KeymapNotify event, serial 20, synthetic NO, window 0x0,


This did work when we originally spoke in the other thread, but it seems to fail now.

==EDIT==
Also, FWIW, I had three windows open in Firefox, but one window stole input from the other two. I just created another new window, and then I had two windows that would accept input, and two that would not. Then one of them miraculously fixed itself, so I now have three working and one not accepting input.

Seems a bug in xev. 1.2.1 here and I get no keyboard or mouse press/release events on any client

What's strange is that even after changing focus stealing prevention to "off", I just had a case where Firefox did not jump to the front.

Off topic, but either Firefox does not claim activation (does the taskbar entry start to blink?), RSSOwl claims it "back" or Firefox cannot raise above whatever window covers it.
There're some patches pending reg. FSP (incredibly nasty topic)

I just had the same bug again in Firefox, after changing focus stealing prevention to none.

Ok, Firefox/Mozilla/XUL can confuse itself on its own then - without even minor assistance of the WM

Again, as in Thunderbird, I could select text in the windows, but the window that looked to be front-most but wasn't receiving input had its text selected in the "background" grey, whereas the other window that stole all input had text shaded in the "foreground" blue.

This just reflects FF/TB opinion about which window is "active". Despite that's actually not strictly related to the keyboard focus[1] we figured in the other thread, Firefox is wrong here.
Unfortunately we don't have xev available to verify this is still the case, but - given only Mozilla clients seem affected - i've no reason to believe different. XUL simply dispatched the events to the wrong window.

Did you meanwhile report a bug to Firefox/Mozilla - and did you get any reply on it?

[1] There's

Code: Select all

xprop -root | grep -E '^_NET_ACTIVE_WINDOW'

It's however reasonable to use the keyboard input as indicator.
Nevertheless, check whether this window matches the one that should or the one that does have the focus (that one's tricky, since you must not activate a konsole window to figure it - but Ctrl+Alt+F1 ie. VT1 should do)

I didn't actually submit a bug report to Mozilla, because at one point I thought it had resoled itself. I will do this now, since it's driving me insane!

I tried using your recommended code, but added `sleep 1` to that I could use it in a normal terminal.

Code: Select all

$ 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_ACTIVE_WINDOW'
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x3c001f6
$ sleep 1 && xprop -root | grep -E '^_NET_ACTIVE_WINDOW'
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x3c0670c


So essentially it seems like KDE/X do see the correct active window, and it's something in the Mozilla application screwing up.

==EDIT==
Bug report filed.

I am experiencing this same behavior. It's been a very aggravating several weeks LOL

I don't think that this is exclusively a Mozilla/TBird/FFox issue. The reason I think this is that I can login to another distribution, e.g., XFCE or Blackbox and the errant focus behavior ceases. I'm in XFCE right now and have used TBird all day without once seeing the focus issue. Like the original poster I tried most of the focus options in the SystemSettings without positive effect. So, in XFCE TBird behaves like one expects. If I login and change my session to KDE, the issue resumes. That would lead me to conclude there is something that KDE is doing, or something about how KDE manages focus transfer to new child windows that TBird is freaking out about.

I'm interested in knowing what if the original poster has any followup information.

Regards,

Guy S.

See the Firefox issue where it was figured that

When the non-responsive window was in the front, xev showed it still registering keystrokes. I also tried xev for the background window that was acting on the keystrokes. No keystrokes were registering from xev.

Notice that esp. patched versions like blue-shell (can't say about vanilla) detect the running session and inject plugins for better desktop integration - which could easily be the culprit here.

I don't know how FF figures the running session, but you cou try

Code: Select all

unset KDE_MULTIHEAD
unset KDE_SESSION_VERSION
unset KDE_FULL_SESSION
unset KDE_SESSION_UID
unset XDG_CURRENT_DESKTOP
unset DESKTOP_SESSION
firefox


gstalnaker wrote:I'm interested in knowing what if the original poster has any followup information.

I don't really have any follow up information. I haven't heard from the Mozilla devs. In my experience, they are incredibly unresponsive generally.

The only other thing is that this (as I posted in the bug report) might help somewhat in Thunderbird (although now Firefox is equally recalcitrant for me).

I was also hit by this (unrelated?) bug in the upgrade. https://bugzilla.mozilla.org/show_bug.cgi?id=917027

Applying the fix for that bug seems to mitigate this bug a little, although it doesn't totally fix it. I still get this bug intermittently, but it *seems* to be less frequent.

The fix is: Edit > Preferences > Advanced > General > Config Editor. Search for mail.compose.max_recycled_windows, double click it, and change the '1' to '0' in the 'Enter integer value' window that pops up.

luebking wrote:Notice that esp. patched versions like blue-shell (can't say about vanilla) detect the running session and inject plugins for better desktop integration - which could easily be the culprit here.

I actually uninstalled blue-shell firefox when I first tried to troubleshoot, and am now using vanilla.

However, it's interesting that my mozilla bug has one comment confirming it… also in a Kubuntu install. I might try posting over at the Kubuntu forums when I get a chance and see if they have any input.

==EDIT==

luebking wrote:I don't know how FF figures the running session, but you cou try

Okay, I'm not 100% sure what these commands do, but I'll try this for a few days and see if they help.

==EDIT2==
No, this didn't help. I just hit the same bug in firefox. I also checked out the command-line output. I'm not sure if relevant, but the only thing that was unique around the time of this event was the following (twice):

Code: Select all

(firefox:21621): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion `targets != NULL' failed


I'm also suffering this problem in Unity.

When I see the list of messages and click Reply or Write, I sometimes can not focus on the new window. But I discovered a trick: I click in the text area, then Spelling, I close the spelling window and then I can type the message. The Spelling window somehow resets the focus.
This problem has made me loose and corrupt messages: when I open TB it asks for a password. I autotype the password from KeepassX. Since the key presses sometimes miss the password input field, TB directly receives the characters of my long password, which do all kinds of crazy stuff very fast, sometimes damaging my messages.

I suspect it's not limited to TB. Sometimes I have accidentaly deleted files because the wrong window received the DEL key press in Nautilus. But I don't know how to describe the problem, and who to tell about it. Suggestions are welcome.

It makes me think I should have stayed at Ubuntu 12.04.

funpro wrote:I'm also suffering this problem in Unity.

Do you really mean Unity? (You know this is a KDE forum, right?) But if you really do, then this could indicate that something is wrong in the interface between Ubuntu (the distro) and the Mozilla applications. I've tried directly downloading Thunderbird, and still have hit this bug, so it's not something that is in the Ubuntu package per se.

funpro wrote:When I see the list of messages and click Reply or Write, I sometimes can not focus on the new window. But I discovered a trick: I click in the text area, then Spelling, I close the spelling window and then I can type the message. The Spelling window somehow resets the focus.

Yes, I've found a similar workaround borne out of frustration. I click a dozen times on the message, and if it's html, then the html edit window appears. This also seems to reset it.

funpro wrote:This problem has made me loose and corrupt messages

Yes, it's very frustrating. I have had to "undo" deletes often. And I'm paranoid that I've missed something.

funpro wrote:I suspect it's not limited to TB. Sometimes I have accidentaly deleted files because the wrong window received the DEL key press in Nautilus

That's interesting that you suspect that. As I say this is a KDE forum, and I'm using KDE, so I don't even have Nautilus. I've certainly only noticed it in Mozilla applications.

Window recycling sounds interesting.
Can you reproduce the issue with compositing turned off/suspended (Shift+Alt+F12)?

Because of unity + nautilus: there could be an issue with GTK interpreting "unexpected" visibility changes, see https://bugs.kde.org/show_bug.cgi?id=191114

The commands unset all environment variables that suggest "this is a KDE session", but
a) that only applies for the very shell they were issued in (firefox must not be run from kickoff or another konsole window/tab)
b) there'd be no guarantee FF would determine the session this way

luebking wrote:Window recycling sounds interesting.

Yes, but as I mentioned, it don't think it totally fixes the bug (in Thunderbird), just reduces the frequency. Besides, I hit this in Firefox without creating any new windows, so I presume that means it can spontaneously occur regardless of window recycling.

luebking wrote:Can you reproduce the issue with compositing turned off/suspended (Shift+Alt+F12)?

I'll try with compositing turned off for a few days.
EDIT2: I've hit this bug again with compositing off.

luebking wrote:The commands unset all environment variables that suggest "this is a KDE session", but
a) that only applies for the very shell they were issued in (firefox must not be run from kickoff or another konsole window/tab)
b) there'd be no guarantee FF would determine the session this way

Ah okay. Nice idea! However, I did launch FF and TB from the same shell, so I guess this is not conclusive either.

==EDIT==
I'm not sure if this is relevant, but when I compose a message, the font style is "variable width". After about half a second, it changes to "sans-serif" by itself. This seems totally unrelated except for the fact that it's approximately the amount of time that it takes for this bug to appear. That is, I can almost always type in the correct window for the first half second, and then (if the bug is going to appear), it's often half a second later.

Some "smart" feature that makes you spamming your fellas with html mails?

Ie. you start typing a textmail, then thunderbird "thinks" you want to write an html mail, replaces the editor and messes that up?
Can one downforce html mail creation? Has that any impact?

sparhawk wrote:

funpro wrote:I'm also suffering this problem in Unity.

Do you really mean Unity? (You know this is a KDE forum, right?) But if you really do, then this could indicate that something is wrong in the interface between Ubuntu (the distro) and the Mozilla applications. I've tried directly downloading Thunderbird, and still have hit this bug, so it's not something that is in the Ubuntu package per se.

Unfortunately yes, I mean Unity. I know this is a KDE forum but this was the only mention I found about this issue.
Has someone updated to 13.10 and in that case, does it help?