Maximize window on primary screen gives small window

[afhp-2020]

Version 1.0.1 (1.0.0-45-gb1072488), built yesterday evening.
Xrandr: primary 1920x1200+0+240, secondary 900x1440+1920+0.

Any window maximized on secondary screen behaves normally and goes fullscreen on that display.
Any window maximized on primary screen ends up, as per FvwmIdent, sized 1862x211. The width is correct, taking into account struts for a panel; the height, obviously, has been miscalculated.

I had not updated Fvwm in quite a while, no idea when this appeared.

[issue-label-bot]

Issue-Label Bot is automatically applying the label bug to this issue, with a confidence of 0.92. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[ThomasAdam]

Hi @afhp-2020,

Odd -- this is one of these things I've never been able to reproduce. Issue #250 was recently created for (I think) the issue you're describing. If you revert 57050fb does this help at all?

If not, I'll have to roll my sleeves up and take a look. Is there anything in your config which might be relevant for me to reproduce this? I maximize windows all the time on different monitors, at different resolutions and don't encounter a problem, so if it's failing for you, I'm guessing there'll be some sort of config option you have which I don't.

[afhp-2020]

Hi Thomas,

I did see #250 but figured it would be a different issue since in my case it's the primary that misbehaves.

Is there an easy way to revert a specific commit (I still don't get the hang of git) or should I just manually change the file back in my local tree ?

As for other elements in my config, I haven't modified it in months and it was working normally until today when I updated and rebuilt.

[ThomasAdam]

Hi @afhp-2020

I suspect the comment about "monitor 2" is misleading, as the maths applies to any monitor -- it's just that it was the second monitor where the issue was noticed.

In terms of what you need to do in git to revert that commit, you just need to type:

git revert 57050fb9b6eb1e5cf903a8f333409ba5caa38040

Then do the usual make clean && make ... dance. If that doesn't help fix things, then you can run:

git reset --hard @{u}

... to put you back to where you were, which also undoes the git revert change so that you're back to how things were.

If you're feeling really adventurous, you could also look at how to use git bisect to pinpoint which commit introduces this problem you're seeing. Fundamentally, if you are able to give me really specific instructions on how to reproduce this, git bisect i what I'd end up using to isolate the fault.

[afhp-2020]

Getting weirder.

As I mentioned, no change locally in quite a while, I think I rebuilt shortly after 1.0.0 got release status and did not observe any change or bug at that point.

With the current (latest) code, Restarting without logging out will randomly and incorrectly maximize one or more window; on the current test, one window (Firefox) maximized as described at the beginning of this issue, another (Xfe) maximized in X but not (apparently) in Y (and manually maximizing again bring us back to the top of this issue).

I'll let it rest for the night and do further and more complete tests tomorrow.

[ThomasAdam]

Right. Might be related to #143

[afhp-2020]

Hello Thomas,

Before trying to delve into git bisect, here are a few points:

• version 1.0.1 "release" from tgz exhibits the behavior described here and in Style PositionPlacement ignores y percentage #265
• version 1.0.0 "release" from tgz does not build due to Unable to build 1.0, bson.h not found [FreeBSD 12.1] #200
• I had enough of a mind (this time...) to make a backup of my working setup before updating, so I can precisely say that 1.0.0-21-ge2c929d5 behaves normally wrt both this issue and Style PositionPlacement ignores y percentage #265.

That's a start, I'll try and see if I can refine it any further.

[ThomasAdam]

Hi @afhp-2020

OK, cool. So you're saying this is fixed?

[afhp-2020]

No, I'm saying I had a backup to a working version for once :)

Tried bisecting (from within my "broken" build dir) and arrived at:

90f7b45841e534819ebe69232528613069217203 is the first bad commit
commit 90f7b45841e534819ebe69232528613069217203
Author: Thomas Adam <[email protected]>
Date:   Sat Oct 3 00:59:47 2020 +0100

    EWMH area: don't crop the boundary

    When getting the working EWMH area, don't crop the boundary to the
    screen edge.

 fvwm/ewmh.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

Both this issue and #265 appear at the same time.

[ThomasAdam]

OK. If you "git revert" this commit, do things work as expected?

[afhp-2020]

Trying to simply revert that commit led to a conflict. Not sure I resolved it right.

That said, fvwm/ewmh.c changed (back ?) to

   1110         nx = max(*x, area_x);
   1111         ny = max(*y, area_y);
   1112         nw = min(*x + *w, area_x + area_w) - nx;
   1113         nh = min(*y + *h, area_y + area_h) - ny;
   1114
   1115         *x = nx;

(line numbers from less)

and both this and #265 are fixed.

Resulting build identifies itself as (from FvwmConsole) version 1.0.1 (1.0.0-47-g8c110042),
git log show my revert just after commit 8c1100...eb1787.

Hope this helps.

[ThomasAdam]

Hi @afhp-2020

OK. So that change was introduced by me (90f7b45) to fix a problem where PositionPlacement undermouse stopped working on monitors where the x/y positions were >0.

I suspect #251 is related somehow as well.

I'll have to think about how best to fix this.

[phileimer]

I agree with Thomas this issue might be related to the #251 I proposed to fix maximize on monitor 2.
I'll try and have a look at this.

[phileimer]

I tested the latest git version - fvwm3 1.0.1 (1.0.0-48-ge3d35880), and was not able to reproduce this 'maximize gives a small window'.

At a moment, I thought I had reproduced the default, but I think I fell into a normal behavior: I moved a maximized window from monitor 2 to monitor 1, then wanted to maximize it on monitor 1, as my monitor 2 is smaller. This second 'maximize' is then treated as 'un-maximize', giving a smaller window. It's because the 'move' keeps the maximized status, which happens to be erroneous in my bigger monitor 1 case.

I can't either reproduce #265: PositionPlacement works fine for me.

[ThomasAdam]

Hi @phileimer

Thanks for checking this. I've not been able to reproduce this either. @afhp-2020 -- is there any other bits of information/setup you can detail to us which might help?

@phileimer -- with respect to the move example, that's the correct behaviour at the moment.

[afhp-2020]

Hi Thomas,

Sorry for the lag, didn't check messages recently.

As I mentioned, this is a pretty stable configuration that worked for months on end before this appeared. I really have no idea.

The only thing I can think of that might remotely be relevant is the atypical screen disposition with the bigger primary is landscape mode and the smaller secondary rotated counter-clockwise to portrait, aligned at the bottom.

No clue otherwise, and no inkling as to where the vertical size of 211 came from, or why PositionPlacement is affected at the same time (then again, also only in Y).

That's probably not very helpful, I'm sorry. I really can't see it.

[ThomasAdam]

Hi @afhp-2020

Ah -- thanks for the extra information! I think you've hit the nail on the head. If you've got a rotated display, then that might explain things, similar to what's happening in #271.

Can you put the output of xrandr -q here, as well as setting BugOpts DebugRandR On in your config (or via Fvwm{Prompt,Console}, enabling fvwm3 logging (fvwm3 -v ... or pkill -USR2 fvwm3) and putting the log file output here as well?

[afhp-2020]

DebugRandR and ExplainWindowPlacement are on in the config, I just purged the old log file (was getting huge, I should keep an eye on it...), USR2'ed and Restarted.

Here are the new, clean log and the Xrandr output.

fvwm3-output.log

xrandr.txt

[snowkat]

I'm seeing a similar issue where windows are being generated too wide with only one display involved. The EwmhBaseStruts in my config is set to:

EwmhBaseStruts 134 0 0 0

While maximized windows are offset to the right correctly, they have a width of 1366px instead of 1232px.

For reference, Xrandr reports the resolution of the display as 1366x768+0+0.

Running git bisect led me to commit 90f7b45841e534819ebe69232528613069217203, and reverting the commit for the following two lines resolves the issue:

--- a/fvwm/ewmh.c
+++ b/fvwm/ewmh.c
@@ -1109,8 +1109,8 @@ void EWMH_GetWorkAreaIntersection(
    }
    nx = max(*x, area_x);
    ny = max(*y, area_y);
-   nw = min(*x + *w, area_x + area_w);
-   nh = min(*y + *h, area_y + area_h);
+   nw = min(*x + *w, area_x + area_w) - nx;
+   nh = min(*y + *h, area_y + area_h) - ny;
 
    *x = nx;
    *y = ny;
``

I'm not sure if this is the same issue considering I only have one display, but since it seems to stem from the same commit, I thought I'd post my findings here in case it helps.

[ThomasAdam]

Hi @snowkat

Thanks. Per the comments already in this thread, we've already identified 90f7b45

[ThomasAdam]

Hello all,

Please can I ask you to test the ta/fix-basestruts branch or me? I'm hoping this addresses some/all of the concerns raised in this bug and a few other related bugs. Specifically, I'm hoping it addresses:

• Correct handling of EwmhBaseStruts setting -- either globally, or using screen XYZ as part of the EwmhBaseStruts command
• Maximizing windows takes into account EwmhBaseStruts, and/or if not set, correctly maximizes to the size of the screen overall -- and hence, you shouldn't see a difference between maximizing a window on any monitor.

In talking to @lgsobalvarro on IRC, he's helped test this, but I want to gather as much information as I can to ensure I've not missed anything.

[NsCDE]

FTR:

This behaviur is identical on both FVWM 2 and FVWM 3.

When primary monitor is smaller than secondary, EwmhBaseStruts is used from the bigger one. If for example EwmhBaseStruts is 0 0 0 86 and there is panel on the bottom of the screen, Maximize on single headed system will put window up to the panel in pixel precision. On above described setup, if for example primary is 1400x1050 and secondary monitor 1920x1080, approx. 1/4 of the panel will get covered with maximized window. If primary is even smaller (tested with 1600x900), there will be no visual difference between "Maximize" and "Maximize ewmhiwa".

[phileimer]

Hi @ThomasAdam,
I didn't notice any problem maximizing/un-maximizing different windows on my two monitors (1920x1080, 1280x1024).

[ThomasAdam]

Hi @phileimer

Thanks. Are you also therefore confirming that there's been no regressions as far as you can tell? I know you had that weird issue where maximizing failed on your second monitor.

[phileimer]

I confirm: no regression noticed.
I continue using this branched version on my main system, and will tell you if something is happening.

[ThomasAdam]

Thanks!

Given other feedback I've had outside of this thread, I'm inclined to merge this code and create separate issues as/when things come up, as I'm sure they will. ;)

[afhp-2020]

Sorry, I couldn't get around to checking this branch in time. I updated from master today (with this commit included) and confirm the issue is fixed, as well as #265.
Regards.

[ThomasAdam]

Hi @afhp-2020

Glad to hear it! Thanks for letting me know.