Windows is continous flashing in loop

[totaam]

Issue migrated from trac ticket # 790

component: client | priority: major | resolution: fixed | keywords: firefox

2015-01-23 03:28:57: John1221 created the issue

---

Reproduce:

1. Server (Ubuntu 12.04), Client (Windows 7), xpra 0.14.18 8503
2. Start and attach xpra with tcp
3. Open Firefox or something.
4. Minimizing and restoring a Firefox window very quickly until the system got stuck in this loop, continuously flashing the window.

[totaam]

2015-01-23 03:31:55: totaam changed owner from antoine to John1221

[totaam]

2015-01-23 03:31:55: totaam commented

---

Can you reproduce with something else, like an xterm?
Or does this have to be firefox?

It really does sound like the bug that I thought I had fixed in 8336 / 8387.
(which is also responsible for the chrome window's lack of responsiveness from the system tray)

[totaam]

2015-01-23 04:13:00: John1221 commented

---

Replying to [comment:1 totaam]:

Can you reproduce with something else, like an xterm?
Or does this have to be firefox?
I'd just reproduce with Opera, Thunar and xterm( it seem hard to reproduce )
and this bug still occur.
I can't reproduce Chrome because it can't minimize by click in it from the taskbar

[totaam]

2015-01-23 04:14:45: totaam commented

---

OK, I can't reproduce it here - not sure why.

Can you please post the client output with the debug flag: -d window

[totaam]

2015-01-23 08:07:48: totaam commented

---

I've bumped the delay which tries to prevent this race from 50ms to 150ms in r8534. Does that help? (included in latest beta 0.15 packages)

[totaam]

2015-02-04 02:52:03: John1221 changed owner from John1221 to totaam

[totaam]

2015-02-04 02:52:03: John1221 commented

---

Replying to [comment:4 totaam]:

I've bumped the delay which tries to prevent this race from 50ms to 150ms in r8534. Does that help? (included in latest beta 0.15 packages)
I'm sorry for very late reply. I forgot this...
I'm using xpra beta 0.15 r8603, and splash still occur.
This issue occur when:

1. Minimizing and restoring a Firefox window very quickly until the system got stuck in this loop, continuously flashing the window, as I described before.
2. Sometimes, when I opening a Firefox (Firefox is crashed before), this issue also occurs. I can't reproduce this case.

[totaam]

2015-02-04 02:53:25: John1221 uploaded file splash150204.txt (21.8 KiB)

Splash window

[totaam]

2015-02-04 10:14:13: totaam changed owner from totaam to John1221

[totaam]

2015-02-04 10:14:13: totaam commented

---

I couldn't reproduce it here - could be because when I test my server latency is lower?
So r8618 attempts to take the server latency into account to know how long to wait before it should be safe to send the "unmap" (iconified) message.

Can you post your:

xpra info | grep latency

If it happens again, can you please try with -d window,state, I've added the "state" debug flag to track problems like this one.

[totaam]

2015-02-05 01:40:25: John1221 uploaded file splashing150205.txt (8.4 KiB)

Firefox window is splashing => xpra info | grep latency

[totaam]

2015-02-05 01:41:03: John1221 uploaded file afterkillsplashingwindows_150205.txt (6.3 KiB)

After kill splashing windows => xpra info |grep latency

[totaam]

2015-02-05 01:41:55: John1221 uploaded file splash150205.txt (273.3 KiB)

Log from client with -d window,state

[totaam]

2015-02-05 01:52:51: John1221 changed owner from John1221 to totaam

[totaam]

2015-02-05 01:52:51: John1221 commented

---

It still occurs again. This is how I reproduce:

1. Attach xpra with tcp
2. Open Firefox.
3. Left-click on Firefox button from taskbar as fast as I can, until the problem occurs.
   I know that 3rd step is deliberate, and maybe no one do that. But as Windows is continous flashing in loop #790#comment:5
   I can't reproduce clearly the 2nd case, and I think 2 case are the same reason.

[totaam]

2015-02-05 02:04:09: totaam changed status from new to assigned

[totaam]

2015-02-05 02:04:09: totaam commented

---

I know that 3rd step is deliberate, and maybe no one do that.
[[BR]]
Maybe, but it's still a bug and we want to fix it.
Thanks for the logs. I think can see what is happening: we are caught in a loop with the maximized state toggle as well as iconified. Those are sent and handled separately, which may be the cause of these problems.

[totaam]

2015-02-05 05:13:22: antoine commented

---

Got it, I had to make the window maximized first to reproduce the bug, otherwise I just could not hit it.

r8623 fixes this for trunk, backport to v0.14.x in 8627. New beta builds uploaded for both versions.

@john1221: can you still break it somehow?

[totaam]

2015-02-05 07:45:39: John1221 changed status from assigned to new

[totaam]

2015-02-05 07:45:39: John1221 changed owner from totaam to antoine

[totaam]

2015-02-05 07:45:39: John1221 commented

---

This bug no longer appears. But I found others bugs. I created 2 tickets: #801 and #802

[totaam]

2015-02-05 07:46:39: totaam changed status from new to closed

[totaam]

2015-02-05 07:46:39: totaam set resolution to fixed

[totaam]

2015-02-05 07:46:39: totaam commented

---

OK, thanks. Closing.

I assume that those new tickets are not regressions caused by this fix?

[totaam]

2015-02-13 04:01:02: John1221 uploaded file flash1502131044.txt (36.9 KiB)

Flashing window when restore previous session from Firefox

[totaam]

2015-02-13 04:02:10: John1221 changed status from closed to reopened

[totaam]

2015-02-13 04:02:10: John1221 removed resolution (was fixed)

[totaam]

2015-02-13 04:02:10: John1221 commented

---

Sometimes, this bug still occurs.
Tested with xpra beta 0.15.0 r8632
Reproduce:

• Open Firefox from xterm.
• Firefox maximized and showed "Restore Previous Session" tab. ( Firefox was last closed or terminated unexpectedly ). Press "Restore" button.
• The Firefox window is continous flashing about 30s.

[totaam]

2015-02-13 04:03:21: John1221 changed status from reopened to new

[totaam]

2015-02-13 04:03:21: John1221 changed owner from antoine to totaam

[totaam]

2017-08-21 17:22:14: ss7 removed resolution (was fixed)

[totaam]

2017-08-21 17:22:14: ss7 commented

---

As I wrote above, 2.2-20170812r16688-1 is affected.
Also, I'm pretty sure my server didn't answer 404.

[totaam]

2017-08-21 17:45:55: antoine commented

---

Also, I'm pretty sure my server didn't answer 404.
No, but the link you posted will go 404 at some point in the future, making this ticket useless.
Also the logs are huge, I'm not going to skim 50MB of log files.

Please try a different window manager to narrow down the problem.

[totaam]

2017-08-21 21:17:35: ss7 commented

---

No bug when attached in xfwm4. The only strange thing in xfwm4 is that all firefox windows appear minimized after every attach.
Ratpoison tries to maximize every window, this feature probably interferes with firefox's own size restore, but nevertheless causes no problem without xpra.
What kind of logs are required to track down the issue?

[totaam]

2017-08-21 21:28:41: ss7 commented

---

Also, when flashing, 100% cpu is consumed by firefox.

[totaam]

2017-08-22 02:27:28: antoine changed status from reopened to new

[totaam]

2017-08-22 02:27:28: antoine changed owner from antoine to sa

[totaam]

2017-08-22 02:27:28: antoine commented

---

Please try to attach the "-d geometry,metadata,screen" debug output of both client and server.

[totaam]

2017-08-22 08:19:17: ss7 uploaded file bug790-client-20170822.txt (1001.1 KiB)

flashing on attach to server with multiple firefox windows

[totaam]

2017-08-22 08:20:54: ss7 uploaded file bug790-server-20170822.txt (3997.1 KiB)

flashing - server log

[totaam]

2017-08-22 08:25:29: ss7 commented

---

When flashing, between white flashes, I see the sprites of the game I played yesterday. Ridiculous.

[totaam]

2017-08-22 10:32:58: antoine commented

---

Looking at the logs, I see tons of:

map-window wid=5, geometry=(1, 1, 1678, 1048), client props={'workspace': 65535}, state={'iconified': True}
map-window wid=5, geometry=(1, 1, 1678, 1048), client props={'workspace': 65535}, state={'iconified': False}

It keeps going back and forth between iconified and not for window ids 4 and 5, every few milliseconds.
This doesn't look like an xpra bug. You can try adding "-d state" to the debug flags to confirm, I suspect these events are triggered from window_state_updated which is a signal we get from the window manager.
This ticket was about a race condition between the client and server, but here xpra is not directly involved and is just being spammed with state updates.

When flashing, between white flashes, I see the sprites of the game I played yesterday. Ridiculous.
Complain to your graphics card vendor, this shouldn't happen. The memory should have been wiped.

[totaam]

2017-08-22 12:13:20: ss7 uploaded file bug790-client-20170822-with-state.txt (1160.2 KiB)

flashing on attach to server with multiple firefox windows - with -d state

[totaam]

2017-08-22 12:13:52: ss7 uploaded file bug790-server-20170822-with-state.txt (3981.8 KiB)

flashing - server log with -d state

[totaam]

2017-08-22 12:18:41: ss7 commented

---

Seems like you are right, but the flashing appeared after xpra upgrade, and never appears when firefox runs in ratpoison directly without xpra.
Could you please suggest some workaround?

[totaam]

2017-08-22 12:40:55: antoine commented

---

Please attach the client debug log with "-d window" added, it isn't clear to me if the iconify / deiconify loop is triggered by the window manager or by xpra itself as a response to a map event.

You can also try this patch which may fix things:

--- xpra/client/gtk_base/gtk_client_window_base.py	(revision 16610)
+++ xpra/client/gtk_base/gtk_client_window_base.py	(working copy)
@@ -1107,7 +1107,7 @@
         gtk.Window.do_map_event(self, event)
         if not self._override_redirect:
             #we can get a map event for an iconified window on win32:
-            if self._iconified:
+            if self._iconified and WIN32:
                 self.deiconify()
             self.process_map_event()
 

This would prevent xpra from de-iconifying a window when it is mapped.
(not sure why the window manager would map an iconified window... but whatever)

If that doesn't help then it means that we just get a storm of WM_STATE updates from the window manager (see ICCCM 4.1.3.1), we never even get a chance to tell the server about it. (the window manager toggles every few milliseconds, we tell the server after a variable delay, usually 150ms or above to prevent race conditions - that's what this ticket is originally about).

This is probably triggered by the windows being created all at the same time and all iconified.
When running Firefox locally, your windows will not start minimized, and they will not be created all exactly at the same time.
I can't think of another workaround, you would need to disable the calls to self.iconify() in the client window code until your window manager is fixed.

[totaam]

2017-08-22 14:24:54: ss7 uploaded file bug790-client-20170822+window.txt (1188.6 KiB)

client log with -d window

[totaam]

2017-08-22 14:25:42: ss7 commented

---

I've tried the patch, it doesn't help.
Also, I disabled calls to self.iconify in client/client_window_base.py and client/gtk_base/gtk_client_window_base.py, this didn't help too.

[totaam]

2017-08-28 12:28:56: antoine commented

---

Finally installed ratpoison in a VM and tested it, after figuring out how to do simple things like cycling through windows (..)

Testing older clients against a new server:

• 10400: NOK
• r10000: NOK
• r8400: OK
• r9400: NOK
• 8900: NOK
• 8600: OK
• r8800: OK
• r8850: NOK
• r8825: NOK
• r8812: NOK
• r8806: NOK
• r8803: NOK
• r8801: OK
• r8802: NOK

So r8802 is the problematic changeset, and sure enough it deals with iconification...

I had to workaround this bug in some older versions when testing (number of desktops window property is not set, causing a "None" hello packet error in bencode):

--- xpra/client/ui_client_base.py
+++ xpra/client/ui_client_base.py
@@ -945,7 +945,7 @@
         root_w, root_h = self.get_root_size()
         capabilities["desktop_size"] = [root_w, root_h]
         ndesktops = get_number_of_desktops()
-        capabilities["desktops"] = ndesktops
+        capabilities["desktops"] = ndesktops or 0
         desktop_names = get_desktop_names()
         capabilities["desktop.names"] = desktop_names
         capabilities["desktop_size"] = [root_w, root_h]

And this is the dumb temporary fix I've used to verify:

--- xpra/client/gtk_base/gtk_client_window_base.py	(revision 16721)
+++ xpra/client/gtk_base/gtk_client_window_base.py	(working copy)
@@ -457,8 +457,8 @@
             state_updates["below"] = bool(event.new_window_state & self.WINDOW_STATE_BELOW)
         if event.changed_mask & self.WINDOW_STATE_STICKY:
             state_updates["sticky"] = bool(event.new_window_state & self.WINDOW_STATE_STICKY)
-        if event.changed_mask & self.WINDOW_STATE_ICONIFIED:
-            state_updates["iconified"] = bool(event.new_window_state & self.WINDOW_STATE_ICONIFIED)
+        #if event.changed_mask & self.WINDOW_STATE_ICONIFIED:
+        #    state_updates["iconified"] = bool(event.new_window_state & self.WINDOW_STATE_ICONIFIED)
         if event.changed_mask & self.WINDOW_STATE_MAXIMIZED:
             #this may get sent now as part of map_event code below (and it is irrelevant for the unmap case),
             #or when we get the configure event - which should come straight after

This should be fixed properly in r16722.
@sa: please confirm so I can backport to older branches.

[totaam]

2017-08-28 12:40:38: ss7 commented

---

Can I wait till this version appear in https://xpra.org/beta stretch, or better download/install manually?

[totaam]

2017-08-28 13:23:51: antoine commented

---

You should be able to apply r16722 by hand, otherwise I've just pushed some beta stretch amd64 packages.

[totaam]

2017-08-28 14:47:49: ss7 commented

---

I confirm the bug is fixed for me in v2.2-r16722 (with ratpoison 1.4.8, firefox 52.3.0esr-1~deb9u1).
But, now the firefox/xpra windows are not maximized to fullscreen by ratpoison. In r16688 and earlier this happened sometimes, now it happens always. This is probably unrelated bug, so #790 should be closed.

[totaam]

2017-08-28 16:07:24: antoine changed status from new to closed

[totaam]

2017-08-28 16:07:24: antoine set resolution to fixed

[totaam]

2017-08-28 16:07:24: antoine commented

---

Please file a separate bug for "maximized to fullscreen", and point back to this ticket for reference. (especially if this changes how often the bug occurs - this can help narrow it down)