search

Xpra-org / xpra

Persistent remote applications for X11; screen sharing for X11, MacOS and MSWindows.
https://xpra.org/
GNU General Public License v2.0
1.91k stars 164 forks source link

Windows is continous flashing in loop #790

Closed totaam closed 7 years ago

totaam commented 9 years ago

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 commented 9 years ago

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

totaam commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

totaam commented 9 years ago

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 commented 9 years ago

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

Splash window

totaam commented 9 years ago

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

totaam commented 9 years ago

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 commented 9 years ago

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

Firefox window is splashing => xpra info | grep latency

totaam commented 9 years ago

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

After kill splashing windows => xpra info |grep latency

totaam commented 9 years ago

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

Log from client with -d window,state

totaam commented 9 years ago

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

totaam commented 9 years ago

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

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

totaam commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

totaam commented 9 years ago

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

totaam commented 9 years ago

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 commented 9 years ago

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

totaam commented 9 years ago

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

totaam commented 9 years ago

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 commented 9 years ago

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

Flashing window when restore previous session from Firefox

totaam commented 9 years ago

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

totaam commented 9 years ago

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

totaam commented 9 years ago

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 commented 9 years ago

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

totaam commented 9 years ago

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

totaam commented 9 years ago

2015-02-13 04:03:21: John1221 commented

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

totaam commented 9 years ago

2015-02-13 13:56:24: antoine changed owner from totaam to John1221

totaam commented 9 years ago

2015-02-13 13:56:24: antoine commented

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.

totaam commented 9 years ago

2015-02-14 01:50:57: John1221 uploaded file flash1502140846.txt (73.6 KiB)

totaam commented 9 years ago

2015-02-14 01:54:55: John1221 changed owner from John1221 to totaam

totaam commented 9 years ago

2015-02-14 01:54:55: John1221 commented

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]

totaam commented 9 years ago

2015-03-19 07:58:33: totaam changed status from new to assigned

totaam commented 9 years ago

2015-03-19 07:58:33: totaam commented

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!
totaam commented 9 years ago

2015-03-19 09:30:00: totaam changed status from assigned to new

totaam commented 9 years ago

2015-03-19 09:30:00: totaam changed owner from totaam to John1221

totaam commented 9 years ago

2015-03-19 09:30:00: totaam commented

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)

totaam commented 9 years ago

2015-03-19 15:10:14: totaam commented

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

totaam commented 9 years ago

2015-03-20 23:56:06: afarr commented

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.

totaam commented 9 years ago

2015-03-21 04:43:38: totaam commented

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... [[BR]] 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? [[BR]] Well, it sounds like it is if you've just reproduced it!?

PS: probably the same fix as #809.

totaam commented 9 years ago

2015-03-24 03:56:10: John1221 changed owner from John1221 to totaam

totaam commented 9 years ago

2015-03-24 03:56:10: John1221 commented

@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.

totaam commented 9 years ago

2015-03-24 16:45:53: afarr commented

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.

totaam commented 9 years ago

2015-03-27 02:16:26: antoine changed owner from totaam to John1221

totaam commented 9 years ago

2015-03-27 02:16:26: antoine commented

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.

totaam commented 9 years ago

2015-03-28 02:26:06: John1221 changed owner from John1221 to totaam