xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 4 weeks ago

#790 closed defect (fixed)

Windows is continous flashing in loop

Reported by: John1221 Owned by: sa
Priority: major Milestone: 2.2
Component: client Version: trunk
Keywords: firefox Cc:

Description

Reproduce:

  1. Server (Ubuntu 12.04), Client (Windows 7), xpra 0.14.18 r8503
  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.

Attachments (11)

splash150204.txt (21.8 KB) - added by John1221 3 years ago.
Splash window
splashing150205.txt (8.4 KB) - added by John1221 3 years ago.
Firefox window is splashing => xpra info | grep latency
afterkillsplashingwindows_150205.txt (6.3 KB) - added by John1221 3 years ago.
After kill splashing windows => xpra info |grep latency
splash150205.txt (273.3 KB) - added by John1221 3 years ago.
Log from client with -d window,state
flash1502131044.txt (36.9 KB) - added by John1221 3 years ago.
Flashing window when restore previous session from Firefox
flash1502140846.txt (73.6 KB) - added by John1221 3 years ago.
bug790-client-20170822.txt (1001.1 KB) - added by sa 4 weeks ago.
flashing on attach to server with multiple firefox windows
bug790-server-20170822.txt (3.9 MB) - added by sa 4 weeks ago.
flashing - server log
bug790-client-20170822-with-state.txt (1.1 MB) - added by sa 4 weeks ago.
flashing on attach to server with multiple firefox windows - with -d state
bug790-server-20170822-with-state.txt (3.9 MB) - added by sa 4 weeks ago.
flashing - server log with -d state
bug790-client-20170822+window.txt (1.2 MB) - added by sa 4 weeks ago.
client log with -d window

Change History (62)

comment:1 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to John1221

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 r8336 / r8387.
(which is also responsible for the chrome window's lack of responsiveness from the system tray)

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:2 in reply to:  1 Changed 3 years ago by John1221

Replying to 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

comment:3 Changed 3 years ago by Antoine Martin

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

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

comment:4 Changed 3 years ago by Antoine Martin

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)

comment:5 in reply to:  4 Changed 3 years ago by John1221

Owner: changed from John1221 to Antoine Martin

Replying to 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.

Changed 3 years ago by John1221

Attachment: splash150204.txt added

Splash window

comment:6 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to John1221

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.

Changed 3 years ago by John1221

Attachment: splashing150205.txt added

Firefox window is splashing => xpra info | grep latency

Changed 3 years ago by John1221

After kill splashing windows => xpra info |grep latency

Changed 3 years ago by John1221

Attachment: splash150205.txt added

Log from client with -d window,state

comment:7 Changed 3 years ago by John1221

Owner: changed from John1221 to Antoine Martin

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 ticket:790#comment:5
I can't reproduce clearly the 2nd case, and I think 2 case are the same reason.

Last edited 22 months ago by Antoine Martin (previous) (diff)

comment:8 Changed 3 years ago by Antoine Martin

Status: newassigned

I know that 3rd step is deliberate, and maybe no one do that.


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.

comment:9 Changed 3 years ago by Antoine Martin

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 r8627. New beta builds uploaded for both versions.

@John1221: can you still break it somehow?

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:10 Changed 3 years ago by John1221

Owner: changed from Antoine Martin to Antoine Martin
Status: assignednew

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

Last edited 22 months ago by Antoine Martin (previous) (diff)

comment:11 Changed 3 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

OK, thanks. Closing.

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

Changed 3 years ago by John1221

Attachment: flash1502131044.txt added

Flashing window when restore previous session from Firefox

comment:12 Changed 3 years ago by John1221

Resolution: fixed
Status: closedreopened

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.

comment:13 Changed 3 years ago by John1221

Owner: changed from Antoine Martin to Antoine Martin
Status: reopenednew

I added a new info about it.
attachment/ticket/790/flash1502131044.txt

Last edited 22 months ago by Antoine Martin (previous) (diff)

comment:14 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to John1221

I am unable to reproduce it (maybe due to having different network parameters, especially latency), but maybe r8661 fixes this? (it could be backported as it is relatively harmless - I think)

If not, please post the client output with -d win32,metadata.
It looks like a race between the client and server each trying to (un)maximize the window, I just don't see what causes it, yet.

I have uploaded new beta builds with this change (you will need both a beta client and a beta server to test this change). Note: no Ubuntu 12.04 builds... I'm not even sure that it will be supported in the final release. Time to move on.

Changed 3 years ago by John1221

Attachment: flash1502140846.txt added

comment:15 Changed 3 years ago by John1221

Owner: changed from John1221 to Antoine Martin

Just tested with Server (Ubuntu 14.04, xpra beta 0.15.0), Client(MS Windows 7, xpra beta 0.15.0 r8661) and it's not work.
Bellow is client output with -d win32,metadata.
attachment/ticket/790/flash1502140846.txt

Last edited 22 months ago by Antoine Martin (previous) (diff)

comment:16 Changed 3 years ago by Antoine Martin

Status: newassigned

I still can't reproduce this, but someone else reported the same issue, and I don't doubt that there is a problem here.

Ideas we can try:

  • server side: try setting the window state after calling configure_window instead of before (done in _process_configure_window)
  • server side: don't set things if they haven't changed
  • client side: avoid calling configure_window when all we want to update is the flags?
  • client side: use a timer to call process_configure_event, and check if the metadata update hasn't been sent by a configure event already (or use a timer for those too?) - and do nothing if the value has just been toggled and back
  • client side: unmap-window when we iconify should probably clear the window state store since we send it!

comment:17 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to John1221
Status: assignednew

Lots of updates, found some minor bugs along the way too:

  • r8796: could be the cause (simple fix)
  • r8797: useful for testing if the bug persists: set XPRA_WIN32_WINDOW_HOOKS=0 on the client before running to disable a large chunk of tricky platform code (maybe it would help)
  • r8798: minor fix (unlikely to matter)
  • r8799: refactoring
  • r8800: using a timer to try to prevent what I've seen in your log samples where we toggle the value the toggle it back after just a few milliseconds
  • r8801: when we send metadata update, we no longer call all the window geometry code if the window geometry is not meant to have changed

@John1221: I have uploaded new beta 0.15 builds with those fixes (centos 6.4, 6.5 and 6.6, and MS Windows - more builds later), does that help?
(you may need both an updated server and an updated client to be able to test all those changes - though obviously this should still be compatible with older versions and some of the fixes will work independently, it would actually be useful to know this so that I know what really needs backporting to the v0.14.x branch)

comment:18 Changed 3 years ago by Antoine Martin

r8802 fixes an embarrassing bug and also adds synchronization of more wm states (see #773).
New beta uploaded.

comment:19 Changed 3 years ago by alas

Testing with win32 client 0.15.0 r8802 (your beta) against a fedora 20 0.15.0 r8806 (smo's build) server - I can't reproduce any flashing loop error with firefox (created as a start-child or from a start-child xterm).

I was able to get the firefox to take over top-level focus and refuse to respect any other application, mentioned in #773, but it's no longer reliably reproducible?

One odd detail (well, technically two), maximizing the firefox window on a 4k monitor and playing video while trying to min/restore/min/restore I find that after about three restores the firefox window begins restoring not to maximized dimensions, but rather to the pre-maximized dimensions... and the speakers are sporadically turned off as well (seems random, using the tray to check speaker status shows it to have toggled to "off", switching back to "on" restores sound).

I noticed a couple of tracebacks and messages on server-side... but I'm not certain that they relate (or at least whether or not the all relate) to the sound issue (my guess), so I'll put them here for now.

2015-03-20 16:19:11,560 codec: MPEG-1 Layer 3 (MP3)
2015-03-20 16:19:13,510 using Pulseaudio device 'Monitor of Null Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-03-20 16:19:13,959 codec: MPEG-1 Layer 3 (MP3)
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/subprocess_wrapper.py", line 73, in export
    self.send(signal_name, *list(data))
  File "/usr/lib64/python2.7/site-packages/xpra/net/subprocess_wrapper.py", line 155, in send
    self.protocol.source_has_more()
AttributeError: 'NoneType' object has no attribute 'source_has_more'
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/subprocess_wrapper.py", line 73, in export
    self.send(signal_name, *list(data))
  File "/usr/lib64/python2.7/site-packages/xpra/net/subprocess_wrapper.py", line 155, in send
    self.protocol.source_has_more()
AttributeError: 'NoneType' object has no attribute 'source_has_more'
2015-03-20 16:19:47,427 using Pulseaudio device 'Monitor of Null Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-03-20 16:19:47,900 codec: MPEG-1 Layer 3 (MP3)
2015-03-20 16:20:26,552 using Pulseaudio device 'Monitor of Null Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-03-20 16:20:27,019 codec: MPEG-1 Layer 3 (MP3)
2015-03-20 16:20:35,398 using Pulseaudio device 'Monitor of Null Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-03-20 16:20:35,852 codec: MPEG-1 Layer 3 (MP3)
2015-03-20 16:20:39,262 using Pulseaudio device 'Monitor of Null Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-03-20 16:20:39,752 codec: MPEG-1 Layer 3 (MP3)
2015-03-20 16:21:46,406 using Pulseaudio device 'Monitor of Null Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-03-20 16:21:46,862 codec: MPEG-1 Layer 3 (MP3)
1426893750624   addons.update-checker   WARN    Update manifest for {972ce4c6-7e08-4474-a285-3208198ce6fd} did not contain an updates property
2015-03-20 16:23:12,900 using Pulseaudio device 'Monitor of Null Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-03-20 16:23:13,164 failed to stop sound process <subprocess.Popen object at 0x2843810>: [Errno 3] No such process
2015-03-20 16:23:13,177 failed to stop sound process <subprocess.Popen object at 0x7fc528018090>: [Errno 3] No such process
2015-03-20 16:23:40,956 using Pulseaudio device 'Monitor of Null Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-03-20 16:23:41,399 codec: MPEG-1 Layer 3 (MP3)
2015-03-20 16:23:51,803 using Pulseaudio device 'Monitor of Null Output'

Not sure if -d win32,metadata is liable to be of much use here... and the client outputted nothing unusual, just messages about re-starting the speaker.

comment:20 Changed 3 years ago by Antoine Martin

The AttributeError: 'NoneType' object has no attribute 'source_has_more' error should be fixed in r8807. (it was probably harmless)

What is happening there is that as you generate lots of large screen updates (maximizing / restoring large windows), you are generating so much traffic that the sound goes into underrun / overrun and restarts. Were you using the default queue settings? Maybe add -d sound on the client side to see the sound queue levels when the sound gets restarted.


firefox window begins restoring not to maximized dimensions, but rather to the pre-maximized dimensions...


I don't think we really need to worry about this one, do you?


I was able to get the firefox to take over top-level focus and refuse to respect any other application, mentioned in #773, but it's no longer reliably reproducible?


Well, it sounds like it is if you've just reproduced it!?

PS: probably the same fix as #809.

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:21 Changed 3 years ago by John1221

Owner: changed from John1221 to Antoine Martin

@totaam:
Great. It's work. And like afarr described, Firefox windows state changed from MAXIMIZE to NOT-MAXIMIZE (maybe NORMAL state ? ), but I don't worry about this.

comment:22 Changed 3 years ago by alas

Tested one more time to see about the firefox refusing to yield top level focus... couldn't reproduce with windows client 0.15.0 r8002 against a fedora 20 server 0.15.0 r8006.

And no, I can't imagine the switch to non-maximized being a problem for anyone who toggles min/max/min/max enough to cause it (methinks such users have other issues to keep them busy).

Seems good to close.

comment:23 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to John1221

Some backports for v0.14.x:

Not backported yet:

  • r8797: trivial, but this is more of a new debugging feature
  • r8799: refactoring - clean, but may not be needed
  • r8801: I hope we don't need this one (changes packet contents..)
  • r8802: probably not needed

I've uploaded beta 0.14.22 builds, can you tell me if that still works for you or if I need to backport more? Thanks.

comment:24 Changed 2 years ago by John1221

Owner: changed from John1221 to Antoine Martin

I've tested with 0.14.22, installed both client and server. And with 0.15 ( again ).
It will be work if my mouse click speed is normal, or faster a bit. But if the speed is very fast, like https://youtu.be/ylqkCXCHqdM?t=46s , the window will be flash in loop again.
I found a video from youtube to describe my speed clicker.
In that case( very fast), nobody will do that. Just it's still appeared, and I response. We don't need fix anymore.

comment:25 Changed 2 years ago by Antoine Martin

Milestone: 1.0
Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

I'm keeping this ticket open because although we seem to be handling the normal behaviour well enough now, we can't just rely on users not doing stupid things - they always do.

comment:26 Changed 2 years ago by Antoine Martin

r8800 caused a minor problem, fixed in r8995 and backported in r9004.

comment:27 Changed 2 years ago by John1221

Status: assignednew

I have tested again with the server ( trusty, xpra 0.15 r9016), client ( MS Windows 7, xpra 0.15 r8987). And this problem occurred.
Reproduce:

  1. Server-side: xpra start :100 --start-child=xterm --bind-tcp=0.0.0.0:1000 --no-cursors --no-pulseaudio --no-speaker
  2. Client-side:
    • Attach xpra : Xpra_cmd.exe attach tcp:IPADDRESS:1000 -> A xterm appears.
    • Open a Firefox from the xterm.
    • Maximize the Firefox, maximize the xterm.
    • Minimizing and restoring the xterm window very quickly by mouse click from the taskbar until the problem occurs.

comment:28 Changed 2 years ago by Antoine Martin

John1221: is this a regression from previous 0.15 beta builds? Or does this still require super-fast clicking to trigger?
(if this is a regression, it may have been caused by r9009 / #809).

comment:29 Changed 2 years ago by John1221

@antoine: I think so. I've just tested r8988(server - Trusty) and r8987(client - MS Windows 7) and it still occurs. I feel we don't require super-fast clicking. I can reproduce quite easy.

comment:30 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to John1221

Is this still a problem? I have just fixed an issue in this area, maybe the latest windows beta builds will work for you?

comment:31 Changed 2 years ago by John1221

Owner: changed from John1221 to Antoine Martin

I've just tested again. It works. Beside, two problems from Xpra 0.15.7-r10824 (release)
windows lost images and subwindows lost images
are also resolved with the latest windows beta builds.
Great!! Thank you very much. :)

comment:32 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to John1221

@John1221: ideally I would like to know when I fixed it so that I could backport it to older branches... if/when you get a chance, can you try different win32 builds to try to identify the first known revision that fixed the issue?

As per ticket:809#comment:20, r10790 may be causing us problems in 0.15.x

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:33 Changed 2 years ago by John1221

Owner: changed from John1221 to Antoine Martin

@antoine:
I tried with many win 32 builds, but I can't reproduce this issue again.
I used xpra 0.15.7 for server, and client: 0.14.22, 0.15.0 r8826, 0.15.0-r9202, 0.15.7-r10824... feel good. Then I changed xpra server to older versions(0.15.0-1, 0.14.22, 0.14.21, 0.14.19) and still good. Maybe the issue appear when I'm using xpra beta 0.15.x ( server or client ) instead of release versions ?
Beside, please read ticket:765#comment:15
Thanks :)

Last edited 22 months ago by Antoine Martin (previous) (diff)

comment:34 Changed 18 months ago by Antoine Martin

Milestone: 1.00.15
Resolution: fixed
Status: newclosed

Closing - feel free to re-open if you can reproduce it with the latest releases.

comment:35 Changed 5 weeks ago by sa

Keywords: firefox added
Milestone: 0.152.2
Resolution: fixed
Status: closedreopened

I have this bug.
It seems like regression, because we spotted this after upgrade from 0.14 to 0.17.
Tested with the following setup:

Debian Stretch or Sid
xpra 0.17.6+dfsg-1 or 2.2-20170812r16688-1 in default configuration (0.14.10+dfsg-1 is not affected)
ratpoison window manager
firefox 52.3.0esr-1~deb9u1

This sequence always reproduces the bug:

  1. Open some windows (tested with four) in firefox, then kill firefox, so it will ask to restore session on next start
  2. Start server: xpra start :20 --start-child=/usr/bin/xterm
  3. Attach for the first time: xpra attach :20
  4. Start firefox on xpra display and press "Restore session" button in firefox. Surprisingly, for the first time only it will successfully restore all windows.
  5. Detach from xpra session via Ctrl-C.
  6. Attach again: xpra attach :20

Screen will flash endlessly until xpra killed.

Please suggest any workaround, because this bug effectively prevents me from using xpra.

Last edited 5 weeks ago by Antoine Martin (previous) (diff)

comment:36 Changed 5 weeks ago by Antoine Martin

Resolution: fixed
Status: reopenedclosed

Version 0.17 and 0.14 have been EOL for almost a year and should not be used as they include some dangerous security bugs (more information here: wiki/Packaging/DistributionPackages), please re-open if you can reproduce with a supported version.

And in any case, attach logs, do not use links that will 404. (removed)

Last edited 5 weeks ago by Antoine Martin (previous) (diff)

comment:37 Changed 5 weeks ago by sa

Resolution: fixed
Status: closedreopened

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

Last edited 5 weeks ago by Antoine Martin (previous) (diff)

comment:38 Changed 5 weeks ago by Antoine Martin

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.

Last edited 5 weeks ago by Antoine Martin (previous) (diff)

comment:39 Changed 5 weeks ago by sa

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?

comment:40 Changed 5 weeks ago by sa

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

comment:41 Changed 5 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to sa
Status: reopenednew

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

Changed 4 weeks ago by sa

Attachment: bug790-client-20170822.txt added

flashing on attach to server with multiple firefox windows

Changed 4 weeks ago by sa

Attachment: bug790-server-20170822.txt added

flashing - server log

comment:42 Changed 4 weeks ago by sa

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

Last edited 4 weeks ago by sa (previous) (diff)

comment:43 Changed 4 weeks ago by Antoine Martin

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.

Changed 4 weeks ago by sa

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

Changed 4 weeks ago by sa

flashing - server log with -d state

comment:44 Changed 4 weeks ago by sa

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?

comment:45 Changed 4 weeks ago by Antoine Martin

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.

Changed 4 weeks ago by sa

client log with -d window

comment:46 Changed 4 weeks ago by sa

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.

Last edited 4 weeks ago by sa (previous) (diff)

comment:47 Changed 4 weeks ago by Antoine Martin

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:

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.

comment:48 Changed 4 weeks ago by sa

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

comment:49 Changed 4 weeks ago by Antoine Martin

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

comment:50 Changed 4 weeks ago by sa

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.

comment:51 Changed 4 weeks ago by Antoine Martin

Resolution: fixed
Status: newclosed

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)

Note: See TracTickets for help on using tickets.