Having this problem on several emacs windows today.
GNU Emacs 24.3.1 (x86_64-mageia-linux-gnu, GTK+ Version 3.10.6)
 of 2014-05-30 on ecosse.mageia.org, modified by Mageia

Needing a place to start to further debug this, attached strace to one each windows (with and without bug triggered).  Tried scrolling window with mouse wheel and nothing would happen until I moved the mouse out/in window; then screen updated to where it should be.  Unless it happened too fast to see, no "scrolling" of the window was visible -- only the last and new were displayed.


Examined both strace files and found these notable differences:

Window with bug NOT triggered contains many block/unblock sequences (always paired):
rt_sigprocmask(SIG_BLOCK, [WINCH IO], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [WINCH IO], NULL, 8) = 0

Presuming WINCH means "window change"..(?)

In addition to above paired sequences, window with bug triggered (mouse must exit/enter to resume) contains many items between some block/unblock pairs:
rt_sigprocmask(SIG_BLOCK, [WINCH IO], NULL, 8) = 0
poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{"\177\0\1\0;\0\5\0\232\0@\v\0\0\0\0\n\0\0\0\7\0\16\0[\0\4\0 \0\0\0"..., 40}, {NULL, 0}, {"", 0}], 3) = 40
poll([{fd=7, events=POLLIN}], 1, 4294967295) = 1 ([{fd=7, revents=POLLIN}])
recvfrom(7, "\1\0\253\235\4\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 0, NULL, NULL) = 48
recvfrom(7, 0xc3dcf4, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(7, 0xc3dcf4, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{"\214\32\7\0\1\0\5\0\307\0@\v\377\377\0\0\0\0\377\377\n\0\0\0\7\0\16\0\214\27\n\0"..., 104}, {NULL, 0}, {"", 0}], 3) = 104
poll([{fd=7, events=POLLIN}], 1, 4294967295) = 1 ([{fd=7, revents=POLLIN}])
recvfrom(7, "\1\0\257\235\4\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 0, NULL, NULL) = 48
recvfrom(7, 0xc3dcf4, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(7, 0xc3dcf4, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
rt_sigprocmask(SIG_UNBLOCK, [WINCH IO], NULL, 8) = 0
--- SIGIO {si_signo=SIGIO, si_code=SI_TKILL, si_pid=9931, si_uid=500} ---
rt_sigreturn()                          = 0
[...]
rt_sigprocmask(SIG_BLOCK, [WINCH IO], NULL, 8) = 0
poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{";\0\5\0\232\0@\v\0\0\0\0\n\0\0\0\7\0\16\0[\6\4\0 \0\0\0\0\0\0\0"..., 36}, {NULL, 0}, {"", 0}], 3) = 36
poll([{fd=7, events=POLLIN}], 1, 4294967295) = 1 ([{fd=7, revents=POLLIN}])
recvfrom(7, "\1\0\303\235\4\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 0, NULL, NULL) = 48
recvfrom(7, 0xc3dcf4, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{"\214\32\7\0\1\0@\v\307\0@\v\377\377\0\0\0\0\377\377\n\0\0\0\7\0\16\0\214\27\n\0"..., 104}, {NULL, 0}, {"", 0}], 3) = 104
poll([{fd=7, events=POLLIN}], 1, 4294967295) = 1 ([{fd=7, revents=POLLIN}])
recvfrom(7, "\1\0\307\235\4\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 0, NULL, NULL) = 48
recvfrom(7, 0xc3dcf4, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(7, 0xc3dcf4, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
rt_sigprocmask(SIG_UNBLOCK, [WINCH IO], NULL, 8) = 0
--- SIGIO {si_signo=SIGIO, si_code=SI_TKILL, si_pid=9931, si_uid=500} ---
rt_sigreturn()                          = 0



Also, these LARGE [-]values are only seen on the window with the bug triggered:
--- SIGIO {si_signo=SIGIO, si_code=SI_KERNEL} ---
rt_sigreturn()                          = 1
--- SIGIO {si_signo=SIGIO, si_code=SI_TKILL, si_pid=9931, si_uid=500} ---
rt_sigreturn()                          = 12828768
[...]
--- SIGIO {si_signo=SIGIO, si_code=SI_KERNEL} ---
rt_sigreturn()                          = 41625176
recvfrom(7, "\10\0\217\304\345\370\n\0\273\2\0\0\227\0@\v\0\0\0\0\261\3\360\1\201\0\212\1\20\10\1\2"..., 4096, 0, NULL, NULL) = 64
--- SIGIO {si_signo=SIGIO, si_code=SI_TKILL, si_pid=9931, si_uid=500} ---
rt_sigreturn()                          = -28518012

This bug appears to kick in after about 1 week.  Restart affected gkrellm, and it stops updating about a week later...

1. Playing with settings:
- change gkrellm updates per second -- impacts the number of updates that occur when mouse crosses window boundary, and on Alt+left click on gkrellm titlebar:
- change KDE Window Behavior->Window Actions[Alt+left button] -- some settings cause N updates for a fraction of a second; others fewer updates. Yet others, no updates

2. I run two instances of claws-mail.  At the moment, one instance works fine when clicking online/offline icon (lower-right of app window) -- notification trayicon switches instantly.  The other instance of claws-mail, online/offline notifications to the trayicon are totally ignored when this bug kicks in.

3a. Running multiple emacs sessions grouped in one window (grouping is just a choice -- bug happens without grouping).  One emacs session stops updating...  that is:
- scroll mouse = nothing. Move mouse out of window and scroll occurs
- type = nothing. Move mouse out of window and characters appear
Pretty much any action is "queued" until mouse leaves/enters window.

3b. Ditto for firefox; though bug affects one tab within one of several windows which I run grouped into a single window.

4. clock updates stop. Moving mouse into or out of clock area causes one update. Rarely, a tooltip appears -- moving out does not update clock and tooltip remains. Move mouse back to clock; tooltip disappears.  Clock will not update at all unless mouse moved over it -OR- when raising app windows. With focus-follows-mouse, moving from one window to another does not cause an update; only when raising...

In summary, this bug appears after a few days.  Affected windows remain affected until they are restarted which clears up that one window.  Logging out and back in clears everything for a few days... then...  :(

Re item 2 in comment #3:  if I click online/offline button on claws-mail, nothing happens; but raising another window, or lowering claws-mail does update the trayicon to the current status.

not seeing this after 13 days on Mageia 5

ARGH!!  Seeing this again after 32 days on Mageia 5...
claws-mail tray icon not being updated unless I switch desktops. 
Clock not updating unless I mouse over it; update occurs at same time as "Current Time" popup displays. 
gkrellm not updating unless I mouse in|out -- moving mouse inside gkrellm window does nothing.

Logout/login (no reboot) clears it all up. Will update ~next month. 
Anyone have a clue where I should look?

Started happening again last night...  

New data:  just noticed that if the mouse hovers over a claws-mail trayicon, the new-mail flag will correct itself as the tool tip pops up.

Logout/login 2015-08-30 resolved the issue until this morning. The clock also updates only when the tooltip pops up or disappears -- so display/hide tooltips  forces updates once the bug is triggered.

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new