maximizing browsers on multi-display setup is sizing wrongly

[alas]

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

• Another extremely interesting note... this only happens when both displays are very close to the same size (both 1920 x 1080; one 1920 x 1080 and the other 1920 x 1200; one 1920x1080 the other 1920x1440; 1920x1080 & 2048x1536... but as soon as I reach 1920x1080 & 2560x1440 the maximize begins to behave as expected.

[alas]

1.0 client logs with -d window

[alas]

0.17.x client logs with -d window

[Antoine Martin]

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

[J. Max Mena]

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)

[J. Max Mena]

Connected, maximized, unmaximized, disconnected

[J. Max Mena]

Connected, maximized, unmaximized, disconnected

[J. Max Mena]

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

[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:

• Connect
• Maximize Firefox
• Unmaximize Firefox

[Antoine Martin]

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.

[J. Max Mena]

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

[J. Max Mena]

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.

[Antoine Martin]

try to always clamp to the monitor size when maximized

[Antoine Martin]

just continue to run the other minmax hooks after our one

[Antoine Martin]

continue - but via return value

[Antoine Martin]

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:

• install the latest trunk
• open xpra's library.zip archive in the file explorer (7-zip does it)
• delete xpra/platform/win32/window_hooks.pyc
• drop the replacement file in that same folder, renaming it to "window_hooks.py"
• make sure the updated library.zip file is saved (ie: closing the file explorer window should be enough)
• run the client and test it (the log output with "-d win32" should show some new "is-maximized" debug output with the first patch)

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.

[Antoine Martin]

preserve existing size restrictions if any

[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)

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

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

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

[J. Max Mena]

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

[J. Max Mena]

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.

[Antoine Martin]

@maxmylyn: thanks!

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

[J. Max Mena]

That did it! Closing.

(tested with the r14619 Win client)