MoveToPage 0 1 makes window dissapear from pager and all desks, pagers and monitors

[NsCDE]

• Fvwm3 version (run: fvwm3 --version)

1.0.4

• Linux distribution or BSD name/version

Fedora 33

• Platform (run: uname -sp)

Linux x86_64

Expected Behaviour

Window moved from page "1 1" to "0 1" or from "1 0" to "0 0"

Actual Behaviour

Window gets moved to desk 0, page X -1, and page-Y 0 and becomes invisible on both monitors, all desks, pages and in FvwmPager. It can be find with WindowList click. It will end up on desk 0, page 0 0, upper left corner of the screen.

Steps to Reproduce

Start FVWM3 in per-monitor mode.

`
xrandr --output Virtual-0 --primary --mode 1400x1050 --pos 0x0 --rotate normal --output Virtual-1 --off --output Virtual-2 --off --output Virtual-3 --off

(Four desks, 2x2 DesktopSize (pages) == 16 was my configuration).

FvwmCommand Restart
`

Open one terminal on the Virtual-0, desk/pagex/pagey 0 0 0. Open another one on Virtual-1, desk/pagex/pagey 2 1 1.

On terminal one on Virtual-0 fire up this, and then go with mouse on the Virtual-1 where on d2 x1 y1 is the other terminal with the known window ID (replace w.id from this example).

`sleep 3 && FvwmCommand 'WindowId 0x220000c MoveToPage 0 1'

Window will dissapear from the Virtual-1, but going to 0 1 will not find it. It cannot be visible anywhere until call from WindowList finds it on 0 0 0 (upper left corner). This can also be observed when moving from "1 0" to "0 0". That is, from right to left, but NOT from left to right.

Prior to finding it with WindowList, it can be examined like this:

FvwmCommand 'WindowId 0x220000c Echo $[w.desk] $[w.pagex] $[w.pagey]

This will print CMD_Echo: 0 -1 0 in the fvwm log.

[ThomasAdam]

Hi @NsCDE

Sorry for the delay. Can you look at the ta/gh-608 branch and let me know if this fixes the issue for you or not...

[NsCDE]

ta/gh-608

Hi @ThomasAdam

Sorry it took me time to set the scene for this after a time.

Nope. It is still happening exactly as described in my first report. :-(

[ThomasAdam]

Hmm.

Are you sure?

[NsCDE]

Re-tested. Confirmed. No change unfortunately.

[NsCDE]

Here is the video ...

fvwm3-bug-608.mp4

[solenum]

Any update on this? I'm running 3 monitors and I can't seem to get windows to move between pages correctly at all, this is my config:

Silent Key 1 A SM MoveToPage 0 0
Silent Key 2 A SM MoveToPage 1 0
Silent Key 3 A SM MoveToPage 2 0

When I move a window from a page to a higher number page (0 to 1 or 2, 1 to 2 etc) it works, but if I try to move a window backwards (2 to 1 or 0, 1 to 0 etc) the window vanishes, and then if I hit the keybind again it re-appears sometimes on the target page and sometimes on its original page, it's really wacky and I can't figure out exactly whats happening.

This has been driving me nuts for the past few days, I can't get fvwm functional on a multi-monitor setup because of this.

[ThomasAdam]

Hi @solenum

Can you get me a reproducible config on this? What is your 3 monitor layout? What version of fvwm are you using?

[solenum]

Hi, this is my screen layout (as per nvidia-settings ui, top is HDMI-0, bottom left is DP-0, bottom right is DP-4)

And this is the config (Not my entire config, but I can reproduce with just this config).

InfoStoreAdd term kitty
InfoStoreAdd browser "firefox"
InfoStoreAdd files pcmanfm

DesktopSize 3x1
DesktopConfiguration per-monitor

# keybinds

Silent Key 1 A M GotoDeskAndPage 0 0 0
Silent Key 2 A M GotoDeskAndPage 0 1 0
Silent Key 3 A M GotoDeskAndPage 0 2 0

Silent Key 1 A SM MoveToPage 0 0
Silent Key 2 A SM MoveToPage 1 0
Silent Key 3 A SM MoveToPage 2 0

Silent Key D A M Exec exec rofi -show run

I've just noticed that it seems to specifically be this setting, as removing it prevents this from happening but then I end up with shared desktops for all monitors, which I don't want:

DesktopConfiguration per-monitor

If I hit shift+alt+1 to send a window from page 3 to page 1, it vanishes, if I hit it again it'll appear at page 1 or page 3 (kinda wacky/inconsistent). However if I don't hit shift+alt+1 again and instead use alt+tab to navigate to the now lost window, it appears top left of my top monitor half off-screen.

However if I press shift+alt+2 to move a window from page 1 to 2 or 3 (or 2 to 3), it works and goes to the correct page on the active monitor. It appears to just bug out any time I try to send a window to a previous/lower desk number.

FVWM version (fvwm3-git from aur)

[21:42] >> fvwm3 --version
fvwm3 1.1.0 (1.0.9-6-g4de50e9c)
with support for:  ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS

Edit; Just compiled from source again on latest:main same issue

Interestingly, when I send to page 1 and the window vanishes, and then I alt+tab to get the window back, its top-left of my top monitor and the middle of the window is exactly top left, so 50% of the window is off-screen It actually just puts the top left corner of the window at the top left of the x screen region. Example:

I also tried this and it still acts the same way.

Silent Key 1 A SM MoveToPage DP-0 0 0
Silent Key 2 A SM MoveToPage DP-0 1 0
Silent Key 3 A SM MoveToPage DP-0 2 0

[solenum]

Possibly a useful discovery, Maximized windows don't suffer this issue and move to previous pages fine, only unmaximized windows do the vanishing trick. Not sure if it's specifically it being maximized as in a flag set though, as manually making a window size fit the screen also prevents the bug from happening. Weird math when calculating a position maybe?

[solenum]

Hi @ThomasAdam, I (think) I've found the origin of the bug! not sure if my hacky workaround is any good but it's working for me for now. I've been trying to debug the move_resize.c:_move_window function to find the cause, and I think the issue is somewhere in update.c:update_fvwm_monitor and geometry.c:get_unshaded_geometry.

I've changed line 444 from

		*ret_g = fw->g.frame;

to this.

// geometry.c - line 444

void get_unshaded_geometry(
	FvwmWindow *fw, rectangle *ret_g)
{
	if (IS_SHADED(fw))
	{
		if (IS_MAXIMIZED(fw))
		{
			*ret_g = fw->g.max;
		}
		else
		{
			*ret_g = fw->g.normal;
		}
		get_relative_geometry(fw, ret_g, ret_g);
	}
	else
	{
		*ret_g = fw->g.normal; // <--- changed this
	}

	return;
}

I can now send windows to any desk number and they seem to work without an issue, I've not looked into specifically why this change has resolved the issue yet, I was too busy focusing on the calculated values in _move_window.

Edit: I've done some testing and its now working for unshaded windows/floating windows, and maximized windows. If the window is shaded and move to a previous desk then it does the weird vanishing bug, but that's good enough for me as of right now as I don't really use shaded windows.

If I get time in the week I'll see what else I can figure out, but I'm pretty much a novice to xorg/x11 code.

[ThomasAdam]

@solenum

Yeah -- that's not going to be a good solution at all.

I think part of the problem here is that to update a window's screen after a move, we actually don't update the relative geometry when setting the screen (in update_fvwm_monitor()) -- but we don't want to do that because the geometry has already changed, and we'd get the old values back.

Can you try the following change instead to see if this also works?

diff --git a/fvwm/update.c b/fvwm/update.c
index 265beb5e5..4848b87f7 100644
--- a/fvwm/update.c
+++ b/fvwm/update.c
@@ -667,7 +667,7 @@ Bool update_fvwm_monitor(FvwmWindow *fw)
        rectangle g;
        struct monitor *mnew;
 
-       get_unshaded_geometry(fw, &g);
+       g = (IS_MAXIMIZED(fw)) ? fw->g.max : fw->g.normal;

[solenum]

Ah nice! Tested your fix and it seems to work for all types of windows, shaded, maximized, etc.