"Small windows" end up unrelated to window parent

[totaam]

Issue migrated from trac ticket # 2703

component: server | priority: minor

2020-04-02 09:10:17: stdedos created the issue

---

Same looking ticket as #2697, but somewhat different

With monitor layout [[Image(xpra_monitor-setup_ApplicationFrameHost_2020-04-02_10-50-02.png)]]

Small windows open outside of their parent. See the other attachment for explanation (it's too big to display here).

This happens for all sorts of actions (background indexing, Find !Action/File/Module/Find in Path), sometimes (sometimes they are closer to their original position, but not quite). Their original intent is to pop upwards/downwards (depending on window boundaries, e.g. for background indexing) of at window's center (for the rest). Note that this centers the window (which starts as one toolbar with one textbox), according to its "maximum size", so that it won't look awkward when it's populated with results (1).

Also sometimes it happens that the small windows might open in-between monitor borders - I assume this is because you create the server as one big monitor, which is the bounding box of the monitors. Because Windows "think" they are maximized (#2643, #2651), the center-ish position (1) is at monitor's intersection.

[totaam]

2020-04-02 09:10:29: stdedos uploaded file xpra_monitor-setup_ApplicationFrameHost_2020-04-02_10-50-02.png (9.7 KiB)

[totaam]

2020-04-02 09:10:43: stdedos uploaded file xpra_small-windows-open-outside-of-their-parent.png (1473.6 KiB)

[totaam]

2020-04-02 09:17:20: stdedos uploaded file redact-xpra-2703-geometry.log (159.6 KiB)

[totaam]

Assuming that this is one of the problematic windows from your log, this looks a little bit suspicious:

10:13:00,156 WindowModel.do_xpra_configure_event(<X11:ConfigureNotify \
    {'serial': '0x1588e', 'y': '31', 'x': '1608', 'border_width': '0', \
     'above': '2098754', 'delivered_to': '0x400029', 'height': '668', \
     'window': '0x400029', 'width': '1278', 'send_event': '0'}>) \
    corral=0x400029, client=0x20004d, managed=True
10:13:00,156 WindowModel.do_xpra_configure_event: event is on the corral window 0x400029, ignored

Then the client honours the original position:

10:13:01,134 transient-for=3 : WindowModel(0x20004d), ws=WindowVideoSource(3 : (1278, 668)), pos=(1608, 31)
10:13:01,165 client   4 @28.180 process_new_common: wid=47, OR=True, geometry([2235, 383, 325, 221])=(2235, 383, 325, 221) / (325, 221)
10:13:01,178 client   4 @28.187 set_decorated(True) re-adjusting window location using {'normal': (8, 8), 'fixed': (3, 3), 'minimum': (136, 39), 'menu-bar': 20, 'border': 1, 'caption': 23, 'offset': (8, 31), 'frame': (8, 8, 31, 8)}
10:13:01,179 client   4 @28.190 setup_window() position=(2235, 383), set_initial_position=False, OR=True, decorated=True
10:13:01,181 client   4 @28.193 after removing areas visible on (Standard monitor types) Generic PnP Monitor from [R(2235, 383, 325, 221)]: [R(2235, 383, 325, 221)]
10:13:01,181 client   4 @28.197 after removing areas visible on (Standard monitor types) C32JG5x from [R(2235, 383, 325, 221)]: []
10:13:01,185 client   4 @28.198 OR offsets=None

So the client is just doing what it's told.
The server is ignoring configure events on other windows since r5804 (6 years ago!).

You could try removing the checks to see if that helps:

Index: xpra/x11/models/window.py
===================================================================
--- xpra/x11/models/window.py	(revision 25905)
+++ xpra/x11/models/window.py	(working copy)
@@ -480,15 +480,6 @@
                 event, cxid, self.xid, self._managed)
         if not self._managed:
             return
-        if event.window==self.corral_window:
-            #we only care about events on the client window
-            geomlog("WindowModel.do_xpra_configure_event: event is on the corral window %#x, ignored", cxid)
-            return
-        if event.window!=self.client_window:
-            #we only care about events on the client window
-            geomlog("WindowModel.do_xpra_configure_event: event is not on the client window but on %#x, ignored",
-                    event.window.get_xid())
-            return
         if self.corral_window is None or not self.corral_window.is_visible():
             geomlog("WindowModel.do_xpra_configure_event: corral window is not visible")
             return

[totaam]

2020-04-03 21:21:01: stdedos commented

---

That causes too many bad things: one of them looks like this:

[[Image(http://xpra.org/trac/raw-attachment/ticket/2455/Xpra_cmd_2019-10-19_12-25-26.png)]]
(the "filling" on the right side)

and the windows are inoperable in general.

Apart from that, the patch does not apply at all on v3/Xenial

[totaam]

Sounds like a duplicate of #2595.

Does the problem occur when using the python2 / GTK2 builds?

[totaam]

2020-12-01 09:21:48: stdedos commented

---

Oops 😅

Do you have any recent builds with Py2? Or should I just downgrade?
I assume we are talking about the client ... right?
"Should I expect" that downgrading the client will mess something on the server?

[totaam]

Do you have any recent builds with Py2? Or should I just downgrade?

You have to use the latest release from the 3.0.x branch, ie at time of writing: Xpra-Client-Python2-x86_64_3.0.12-27627.zip.

I assume we are talking about the client ... right?

Yes

"Should I expect" that downgrading the client will mess something on the server?

I don't see how it could.

[totaam]

2020-12-01 09:36:29: stdedos commented

---

FYI client builds have no signatures or hashes. You may want to add them at least for the latest one.

Going testing, but don't hold your breath :-D

[totaam]

2020-12-01 10:42:15: stdedos commented

---

"Xpra-Client-Python2-x86_64_3.0.12-27627\xpra_cmd" attach ssh://user@ip/3 --ssh="plink -ssh -agent" --modal-windows=no --title="@title@ on @@/@server-display@" --headerbar=off --opengl=no --bandwidth-limit=6Mbps

XPRA_CUSTOM_TITLE_BAR=0
XPRA_EXECUTABLE=Xpra-Client-Python2-x86_64_3.0.12-27627
XPRA_REPAINT_ALL=1
XPRA_SCROLL_ENCODING=0

xpra initialization error:
 no such option: --headerbar

But I guess that's expected, right?

Also:

"Xpra-Client-Python2-x86_64_3.0.12-27627\xpra_cmd" attach ssh://user@ip/3 --ssh="plink -ssh -agent" --modal-windows=no --title="@title@ on @@/@server-display@" --opengl=no --bandwidth-limit=6Mbps

XPRA_CUSTOM_TITLE_BAR=0
XPRA_EXECUTABLE=Xpra-Client-Python2-x86_64_3.0.12-27627
XPRA_REPAINT_ALL=1
XPRA_SCROLL_ENCODING=0

2020-12-01 12:42:37,837 Xpra GTK2 client version 3.0.12-27627 64-bit
2020-12-01 12:42:37,845  running on Microsoft Windows 10
2020-12-01 12:42:37,901 Warning: failed to import opencv:
2020-12-01 12:42:37,902  No module named cv2
2020-12-01 12:42:37,902  webcam forwarding is disabled
Warning: failed to import GStreamer 1.x:
 cannot import name _gi
2020-12-01 12:42:38,867 Error: failed to query sound subsystem:
2020-12-01 12:42:38,867  query did not return any data
2020-12-01 12:42:39,110 keyboard layout code 0x409

[totaam]

no such option: --headerbar
But I guess that's expected, right?

Correct.

Warning: failed to import GStreamer 1.x:

Known issue, now with its own ticket: #2961

[totaam]

2020-12-01 13:13:02: stdedos commented

---

Still happens, although I replicated it a little differently (check attachment).

Some comments:

• It also happens when I have one window of the app open similarly
• As with the original screenshot, some small windows (toasts) follow / are anchored to the parent, the "extended progress bar" doesn't/isn't
• It is interesting/nice that the app remembers exactly in which monitor and with what dimensions it was open last time with (although I don't know if that's somehow your doing or the app's)

[totaam]

2020-12-01 13:13:19: stdedos uploaded file Xpra_cmd_2020-12-01_15-06-13.png (641.8 KiB)

[totaam]

Could very well be #3202 (fixed).

[stdedos]

Does not seem to fix the specified "Small window" (background task executer)

[totaam]

5fd33c4 and the refactoring for #3476 may help with this.

[stdedos]

I'll keep it in mind in future interactions; however, I think that this scenario is "indefinitely on hold" for me.

Much more interesting to me "for the time being" is shadowing / "perfect scaling" - full screen / intercept all shortcuts (eg any WinKey shortcut), and basically "latency-free", "realtime" shadow on the same network (100Mbps eth over eth/wifi; rendering from the server "is troubled", even though actions are replicated instantaneously)

[totaam]

Could also be solved by #56 but #1526 may be getting in the way.
The MS Windows API is incredibly frustrating / borderline unusable: we want the actual monitor dimensions, irrespective of any DPI or font scaling but this is too much to ask apparently.

[totaam]

Is this still an issue with Xdummy and xpra v5?

[stdedos]

I'll download updates and test it sometime this week 😁

[stdedos]

It "mostly works correctly", but there are corner cases:

I am not totally disappointed - apart from the few things, v5 looks solid.

[stdedos]

Same thing happens with the right-click menu items - I assume they are not "traditional" right-click menu items

(the white-rendering is tracked in #3989)

[totaam]

It "mostly works correctly", but there are corner cases:

I have no idea what I am looking at. What is wrong here?

[stdedos]

The "Background tasks" window is "a child" to the smaller top-left window.

As Seamless has a "magic geometry" root window, here's an idea I had about it:

The "Background tasks" window, instead of being created .... idk, here

(window.bottom - 20px, window.right - 10px), it instead "assumes" the root window to be a single display, and then it does monitor.bottom - 20px, monitor.right - 10px.

However, I also assume that Seamless display is a little bit like the red here

So, then, monitor.bottom - 20px, monitor.right - 10px (as red) makes sense why that small window lands there instead of inside its seemingly-parent window.

But I'm happy to let this go if this is too complicated to grok and you have other priorities.

[totaam]

Probably the same resolution as this one:
#3989 (comment)
This can only be fixed properly with Xdummy, which Debian is unable or unwilling to fix properly.

[totaam]

I'm going to close this as this is very likely a Debian-only issue.