Closed totaam closed 7 years ago
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.
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.
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:
- Server-side: xpra start :100 --start-child=xterm --bind-tcp=0.0.0.0:1000 --no-cursors --no-pulseaudio --no-speaker
- 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.
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).
Is this still a problem? I have just fixed an issue in this area, maybe the latest windows beta builds will work for you?
I've just tested again. It works. Beside, two problems from Xpra 0.15.7-10824 (release) windows lost images and subwindows lost images are also resolved with the latest windows beta builds. Great!! Thank you very much. :)
@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 #809#comment:20, 10790 may be causing us problems in 0.15.x
@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-9202, 0.15.7-10824... 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 #765#comment:15 Thanks :)
Closing - feel free to re-open if you can reproduce it with the latest releases.
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:
- Open some windows (tested with four) in firefox, then kill firefox, so it will ask to restore session on next start
- Start server: xpra start :20 --start-child=/usr/bin/xterm
- Attach for the first time: xpra attach :20
- Start firefox on xpra display and press "Restore session" button in firefox. Surprisingly, for the first time only it will successfully restore all windows.
- Detach from xpra session via Ctrl-C.
- 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.
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: Packaging DistributionPackages), please re-open if you can reproduce with a [/wiki/Versions supported version].
And in any case, attach logs, do not use links that will 404. (removed)
As I wrote above, 2.2-20170812r16688-1 is affected. Also, I'm pretty sure my server didn't answer 404.
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.
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?
Also, when flashing, 100% cpu is consumed by firefox.
Please try to attach the "-d geometry,metadata,screen" debug output of both client and server.
bug790-client-20170822.txt
(1001.1 KiB)flashing on attach to server with multiple firefox windows
bug790-server-20170822.txt
(3997.1 KiB)flashing - server log
When flashing, between white flashes, I see the sprites of the game I played yesterday. Ridiculous.
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.
bug790-client-20170822-with-state.txt
(1160.2 KiB)flashing on attach to server with multiple firefox windows - with -d state
bug790-server-20170822-with-state.txt
(3981.8 KiB)flashing - server log with -d state
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?
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.
bug790-client-20170822+window.txt
(1188.6 KiB)client log with -d window
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.
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.
Can I wait till this version appear in https://xpra.org/beta stretch, or better download/install manually?
You should be able to apply r16722 by hand, otherwise I've just pushed some beta stretch amd64 packages.
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.
Issue migrated from trac ticket # 790
component: client | priority: major | resolution: fixed | keywords: firefox
2015-01-23 03:28:57: John1221 created the issue