Xpra: Ticket #1354: maximizing browsers on multi-display setup is sizing wrongly

Testing with both 1.0 r14402 fedora 23 server against a 1.0 r14397 windows client and 0.17.1 r 12453 fedora 23 server against a 0.17.5 r13487 windows client... with two displays, I'm finding that maximizing a browser window (chrome, firefox) causes it to size across both displays... but only if I maximize from the left-most display.

Fullscreen with videos behaves as expected.

I'll attach client-side logs for both combinations with -d window... looks like there's a init_max_window_size(..) max-window-size changed from (0, 0) to (4096, 4096), because of max viewport dims (8192, 8192) and max backing dims (4096, 4096) call being made in each case, with a desktop/display set up of:

 desktop size is 3840x1080 with 1 screen:
  Default (1016x285 mm - DPI: 96x96) workarea: 3840x1040
    DISPLAY1 1920x1080 at 1920x0 (621x341 mm - DPI: 78x80) workarea: 1920x1040
    DISPLAY2 1920x1080 (621x341 mm - DPI: 78x80) workarea: 1920x1040


Thu, 10 Nov 2016 22:37:43 GMT - alas: attachment set

1.0 client logs with -d window


Thu, 10 Nov 2016 22:38:04 GMT - alas: attachment set

0.17.x client logs with -d window


Fri, 18 Nov 2016 14:56:43 GMT - Antoine Martin: owner changed

Are there any differences between the 1.0 branch and 0.17? Is this a regression? The log sample for 1.0 does have a maxmimize event:

configure event: current size=(930, 517), new size=(4096, 4096), backing=gtk2.GLWindowBacking(2, (930, 517), None), iconified=False

But the 0.17.x does not. It would be good to have working case vs non-working case, using the same xpra version - to make it easier to compare.

It could also be opengl related: have you tried turning it off? (or on?)

Can you try to run the client with XPRA_WIN32_WINDOW_HOOKS=0 to see if that makes any difference? If it does, then it's going to be one of those flags (unset XPRA_WIN32_WINDOW_HOOKS first): XPRA_WIN32_UNDECORATED_STYLE=0, or XPRA_WIN32_MAX_SIZE_HINT=0 or XPRA_WIN32_GEOMETRY=0.

Please include the debug output with these extra debug flags: "geometry", "screen" and "win32".


Tue, 22 Nov 2016 19:00:50 GMT - J. Max Mena: owner changed

It could also be opengl related: have you tried turning it off? (or on?)


Turning OpenGL off causes the misbehavior to stop.


Can you try to run the client with XPRA_WIN32_WINDOW_HOOKS=0 to see if that makes any difference?


Yes, it makes a difference. I uhh can't maximize anymore - the option is greyed out. So, technically that fixes it. However, I have a feeling that's not an elegant solution.


Option Effect?
XPRA_WIN32_UNDECORATED_STYLE=0 no
XPRA_WIN32_MAX_SIZE_HINT=0 no
XPRA_WIN32_GEOMETRY=0 fixed it!

Looks like the XPRA_WIN32_GEOMETRY=0 option fixed it. Will attach requested logs in a sec (on other machine)


Tue, 22 Nov 2016 19:01:54 GMT - J. Max Mena: attachment set

Connected, maximized, unmaximized, disconnected


Tue, 22 Nov 2016 19:02:05 GMT - J. Max Mena: attachment set

Connected, maximized, unmaximized, disconnected


Tue, 22 Nov 2016 19:02:20 GMT - J. Max Mena: attachment set

Connected, maximized, unmaximized, disconnected - this one worked as expected


Tue, 22 Nov 2016 19:05:32 GMT - J. Max Mena:

Note: I was testing this with a Win8.1 machine with two 1080p monitors attached (one is a 1440p monitor, the other is 4K, but I lowered the resolutions to match), with a r14469 trunk client against a trunk r14470 Fedora 24 server.

My steps were very straight forward:


Wed, 23 Nov 2016 08:48:45 GMT - Antoine Martin: owner changed

The XPRA_WIN32_GEOMETRY controls whether we hook apply_maxsize_hints or not. When we hook it, we will ensure windows don't grow bigger than a certain size. This is needed if the application makes that request, or if we do. ie: to ensure we don't overflow the opengl texture / viewport limits, or to keep it within the "workspace" area. We use our own hook because if we leave to GTK, it hides the maximize button, as you found out.

From your log sample, I see:

apply_maxsize_hints(GLClientWindow(2 : gtk2.GLWindowBacking(2, (1248, 848), None)), \
    {'max_width': 4096, 'min_height': 118, 'base_width': 300, 'max_height': 4096, 'min_width': 300, 'base_height': 118}) found max: 4096x4096

Then later on the system uses our hook to constrain the window geometry:

on_getminmaxinfo window=0x140822 max_size=(4096, 4096), frame=8x8, minmaxinfo size=4112x4135

And also:

OpenGL enabled with Intel(R) Iris(TM) Graphics 5100

It's very likely that this chipset is limited to 4kx4k textures (you can verify with the opengl_check.exe tool)

causes it to size across both displays... but only if I maximize from the left-most display


You're not stating what happens if you're on the right-most display. Does it maximize only on that monitor? What is the difference between "undecorated" and "maxsizehint" logs? Do you have logs of "working" (left) and not-working (right) doing the same steps to compare?

I can't reproduce at the moment since virtualbox doesn't do enough opengl to test.


Wed, 23 Nov 2016 17:26:45 GMT - J. Max Mena: attachment set

Requested log - connected, moved Firefox to the right monitor, maximized and unmaximized twice, moved it to the left monitor, then maximized and unmaximized twice


Wed, 23 Nov 2016 17:30:42 GMT - J. Max Mena: owner changed

If I move Firefox to the right monitor, it'll maximize and unmaximize fine (as in on the correct monitor). Maximizing and unmaximizing on the left monitor causes the browser to maximize across both monitors.


What is the difference between "undecorated" and "maxsizehint" logs?


I used the XPRA_WIN32_UNDECORATED_STYLE=0 flag in the "undecorated" log, and the XPRA_WIN32_MAX_SIZE_HINT=0 flag in the "maxsizehint" log. Same steps for all of them.


Do you have logs of "working" (left) and not-working (right) doing the same steps to compare?


Just attached another log sample. This time, I connected, then moved firefox to the rightmost monitor and maximized and unmaximized a couple times. After a second, I moved it to the left monitor and did the same. On the right monitor it maximized fine, and on the left it maximized across both displays.


Passing back to you.


Thu, 24 Nov 2016 11:24:35 GMT - Antoine Martin: attachment set

try to always clamp to the monitor size when maximized


Thu, 24 Nov 2016 11:25:42 GMT - Antoine Martin: attachment set

just continue to run the other minmax hooks after our one


Thu, 24 Nov 2016 11:26:07 GMT - Antoine Martin: attachment set

continue - but via return value


Thu, 24 Nov 2016 11:32:14 GMT - Antoine Martin: owner changed

I thought I could still test a fix for this with virtualbox by artificially constraining the window size using the --max-size switch, but this is behaving as it should on my XP test vm.

I have attached 4 possible fixes which you can try ("window_hooks.*py") To try them, either make a new win32 build from source after replacing the trunk version of the file with one of the files attached, or:

Rinse and repeat for each potential fix.

If that does not help, please include the "-d all" of just the maximize event for both successful and unsuccessful cases.


Thu, 24 Nov 2016 11:50:24 GMT - Antoine Martin: attachment set

preserve existing size restrictions if any


Mon, 28 Nov 2016 22:24:49 GMT - J. Max Mena:

This one will have to wait a bit as Smo can't get me builds at the moment, and 7Zip isn't playing nicely and won't let me add files to the archive. (lets me delete no problem)


Tue, 29 Nov 2016 03:32:19 GMT - Antoine Martin:

FYI: on my systems I can just double-click on the library.zip to open it up in windows explorer, then I can just drag and drop files inside the archive. Alternatively, you could use the command line: unzip, modify, zip it again.


Fri, 02 Dec 2016 18:39:32 GMT - J. Max Mena:

Found a workaround - copying the file to another folder under my User directory, I can edit it no problems. (ugh Windows and permissions, blegh)

Dropping in the replacement .py file causes the client to no longer connect. I think it doesn't like that I'm replacing a .pyc with a .py file.

Not sure what to do here. Either way, still no builds from Smo - will ping him.


Mon, 05 Dec 2016 12:55:56 GMT - Antoine Martin:

I think it doesn't like that I'm replacing a .pyc with a .py file.


Do not rename the file. Just copy it as ".py" to the target directory after removing the corresponding ".pyc". Without editing or renaming.


Mon, 05 Dec 2016 17:13:14 GMT - J. Max Mena:

That's what I did and it still complains about not being able to import the library.


Thu, 22 Dec 2016 17:22:37 GMT - J. Max Mena: owner changed

Okay, thanks to Smo's hard work, I managed to get 4 different libraries to test. The client is a 1.0 r14492 Win8.1 and the server is at Fedora 24 1.0 r14576.

Here, I'll make a handy table. On the left, I'll note which library file I'm using (each corresponds to the window_hooks) attached to this ticket, and on the right I'll mark if it works and fixes the issue or not.

Which library? Works?
1 works
2 doesn't work
3 doesn't work
4 works

Looks like the first and fourth window_hoooks.py are the ones that fix it. Passing back to you. Let me know if you want any more logs.


Fri, 23 Dec 2016 04:29:23 GMT - Antoine Martin: owner changed

@maxmylyn: thanks!

Applied version 4 of the patch to trunk in r14581, r14582 for v1.0.x


Wed, 28 Dec 2016 22:40:26 GMT - J. Max Mena: status changed; resolution set

That did it! Closing.

(tested with the r14619 Win client)


Sat, 23 Jan 2021 05:21:57 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1354