Window switcher switching back to the previous window immediately about labwc

[pablo-888]

(Sorry I'm so slow at writing English and my last comment was not related to yours)

I think the video you posted doesn't contradict with what we've observed so far.

Can you apply this patch and see the problem still exists? If it does, maybe we're missing something.

This patch alone fixed it for me!. No need to change anything else in my case.

[pablo-888]

I've actually had the same problem but it happens completely at random with no rhyme or reason or way to reliably reproduce it so I didn't report it (plus it doesn't happen that often anyways)

A workaround for me when that happens is minimizing every window (via the Iconify keybind or with wlrctl). I noticed that once every window is minimized, you need to hit the minimize keybind one additionl time for the glitch to go away. Not sure if that info is helpful at all.

[tokyo4j]

I finally figured out why I couldn't reproduce it!
I was using following mouse settings rc.xml:

    <context name="Title">
      <mousebind button="Left" action="Press">
        <action name="Focus" />
        <action name="Raise" />
      </mousebind>
      <mousebind button="Left" action="Drag">
        <action name="Move" />
      </mousebind>
      <mousebind button="Left" action="DoubleClick">
        <action name="ToggleMaximize" />
      </mousebind>
    </context>

But if I moved <mousebind button="Left" action="Press"> to <context name="TitleBar"> (which is default), the problem happens.

[charbelnicolas]

I can now reproduce it 100% of the time.

The way to reproduce it is to minimize/iconify the window you want to glitch then bring up the window switcher with ALT-TAB and then move your cursor to the actual window being previewed so it gains focus and then let go of ALT (or whatever you have set up as modifier key).

[Consolatis]

Combined @tokyo4j's patch with two more checks in the action handlers on cursor click / release:

• #1668

Testing would be appreciated.

[tokyo4j]

I found another bug similar to this: we can still make the inconsistent state by activating the previewed window from wlr-foreign-toplevel-management clients like waybar:

activate-preview-from-foreign-toplevel.mp4

I guess we can address it as another issue though.

[Consolatis]

Thanks for the report. Will try to investigate later.
For now I suggest using an older commit or the last release.

[charbelnicolas]

I don't know what triggered it but it's working fine now... It had never happened to me before and I've been using labwc for more than a month now...

[Consolatis]

Depending on how you compile labwc, sometimes meson seems to mix things up and doesn't re-compile some parts that it should re-compile. That can then cause various random symptoms like this, recreating the build directory (e.g. via meson setup new_build; meson compile -C new_build) should help in this cases.

I am closing this issue for now but please comment / reopen if it happens again. We had some major changes to how the OSD shows and switches between windows somewhat recently so it is quite possible that we missed something there.

[Consolatis]

That sounds like there is indeed something wrong then, 2 people reporting the same issue usually means something slipped through.

[pablo-888]

Yeah the window technically doesn't actually close or destroy itself. it's still there I just have to minimize all windows then after that I can switch between them fine again (I don't need to close them or anything like that). It's sort of like this:

• I'm on firefox.
• I ALT+TAB to switch to the terminal
• The terminal shows itself as it should for as long as I still have ALT pressed.
• Once I let go of the ALT key to actually switch to it, foot disappears. I can keep ALT-TABBING and foot is still there but it just doesn't want to stay up once I let go of the keys.

I've been trying to reproduce on command again trying different things but I can't get it to happen now. (I'm on the latest git yes. Sadly since it happens so rarely and randomly I didn't take note of when exactly this started happening at the time so I just sort of waited it out instead. Bad mistake in hindsight lol).

[pablo-888]

I finally found a (very dumb and obvious) way to reproduce it. Literally just minimize a window and alt+tab to bring it back a bunch of times in a row. (in this case with only firefox and foot open that way I can do it faster. )

I also use the minimize button in the titlebar rather than a keybinding, not sure if that makes a difference but I assume not. If I do this enough times I will trigger the bug. (could be a dozen tries or it could be more but it usually takes no longer than a minute for it to happen).

After playing with the config file just now I found that having Preview enabled is what causes the bug for me. Having Outlines on/off makes no difference. Even before finding the steps to reproduce it I've had Preview off since yesterday and the bug didn't happen even once so I'm pretty sure that's it.

[pablo-888]

sadly it does not. here's a video of it happening with Preview on. (for reference it happens at 00:06. cursor was static beforehand. it took me about 40 seconds to trigger it i just cut some of it out)

output-.00.31-00.52.mp4

you can also see the browser becoming dimmer/lower contrast because it thinks the window is behaving normally and is in front of it even though you can't see it anymore when you switch to it.

edit/additional info before I go to bed: when the bug happens, the panel/taskbar (sfwbar in this case) shows the window like it's currently active/selected even though it has become invisible. To bring it back I have to click on it (again from the taskbar) to minimize it and then after that I can click on it again and it shows up normally.

[Consolatis]

Hm.. so it appears we have to block all mouse input while in A-Tab (e.g. cycle_view is set). If that works its nice to know that there is a workaround. However I still don't understand why this then causes the described behavior, something happening randomly is usually a very bad sign.

[Consolatis]

However, currently I have no idea why moving <mousebind button="Left" action="Press"> to <context name="TitleBar"> fixes this problem.

Title doesn't trigger on the buttons but just the space between the buttons. TitleBar in comparison triggers on the whole top side of the SSD, including the buttons. So if that is the difference that allows you to reproduce the issue it seems either Raise or Focus in combination with OSD window preview + minimize is to blame.

While it might still be interesting to figure out the further error path here to ensure we don't cover up an existing bug that could also be triggered through other code paths in the future we should in any case prevent handling mouse button events while in the OSD. Mouse movement seems fine to me though.

[tokyo4j]

Mouse movement seems fine to me though.

I guess we need to disable <followMouse> when OSD is activated, as it has similar effects as <action name="Focus" /><action name="Raise" /> against minimized windows.

So the patch will look like:

diff --git a/src/input/cursor.c b/src/input/cursor.c
index eb359e7..cec9db2 100644
--- a/src/input/cursor.c
+++ b/src/input/cursor.c
@@ -529,7 +529,8 @@ process_cursor_motion(struct server *server, uint32_t time)
 		dnd_icons_move(seat, seat->cursor->x, seat->cursor->y);
 	}
 
-	if ((ctx.view || ctx.surface) && rc.focus_follow_mouse) {
+	if ((ctx.view || ctx.surface) && rc.focus_follow_mouse
+			&& !server->osd_state.cycle_view) {
 		desktop_focus_view_or_surface(seat, ctx.view, ctx.surface,
 			rc.raise_on_focus);
 	}

[charbelnicolas]

(Sorry I'm so slow at writing English and my last comment was not related to yours)

I think the video you posted doesn't contradict with what we've observed so far.

Can you apply this patch and see the problem still exists? If it does, maybe we're missing something.

I've never applied patches, I only use the AUR on Arch Linux to get the latest git version to update. I don't really know the proper way to do it. Maybe someone else can try!

[charbelnicolas]

Here's another video...

vid_2024_03_18_19_11_33.mp4

[charbelnicolas]

It's actually quite a showstopper bug not being able to switch windows....

[droc12345]

Looks like it's the original way (not all workspaces).

Which version of labwc does this happen on, or which git commit?

Edit to add: Are we cleaning up after making a selection?

[johanmalm]

Does it happen only with Chromium?

Does it happen with both XWayland and xdg-shell clients?

Does this patch make a difference? 9d51107

Does the patch below make a difference?

diff --git a/src/config/rcxml.c b/src/config/rcxml.c
index 994498c..c4a1012 100644
--- a/src/config/rcxml.c
+++ b/src/config/rcxml.c
@@ -1190,7 +1190,6 @@ rcxml_init(void)
 	rc.window_switcher.preview = true;
 	rc.window_switcher.outlines = true;
 	rc.window_switcher.criteria = LAB_VIEW_CRITERIA_CURRENT_WORKSPACE
-		| LAB_VIEW_CRITERIA_ROOT_TOPLEVEL
 		| LAB_VIEW_CRITERIA_NO_SKIP_WINDOW_SWITCHER;
 
 	rc.resize_indicator = LAB_RESIZE_INDICATOR_NEVER;

[pablo-888]

For me it always seems to happen with the foot terminal. (I mostly just have have Firefox and a terminal open)

Like I said you could be using labwc for hours and not have it happen at all. It's very random. I could apply that patch and report back in a few days I guess.

edit: That was quick. It still happens. The terminal vanishes when I let go of alt+tab, but labwc thinks the window is actually there (i can see firefox doing the gtk3 thing where it "dims" itself if it's not in the foreground even though there's no visible window in front of it).

[droc12345]

I usually use foot with firefox also, FF is the wayland only version.
And I can't seem to reproduce that problem.

Are you running the latest git version?

and by disappear, you mean it doesn't show the window at all, but it's still active?
ie, if you do a ps does foot still show?

[droc12345]

are you using outlines and/or preview (window switcher rc setting)?

[pablo-888]

I had outline set to no and preview unset (which defaults to yes I guess). I've just turned preview off to see if it helps i'll report back later.

[droc12345]

Preview unset should default to yes. Which explains it being there and disappearing when alt is released.
But foot, for example, should only disappear if you didn't select that from the window switcher.
And it shouldn't minimize unless you have another action bound to Alt-Tab.
If it was minimized and it wasn't selected then it would return to minimized.

I've found out, by experimenting that
Alt-Tab opens OSD
Alt-Tab (once or repeat) cycles through other windows
Alt-Esc puts you back to where you started, focus remains where it was.
All the above without removing finger from Alt.
When Alt is released whatever is highlighted should be the focused window.

[tokyo4j]

I don't know if this is the same problem, but by following the procedure below, a window can be hidden, although it seems to be activated according to waybar:

1. Minimize a window
2. Select the window by Alt-Tab
3. Move cursor on the preview
4. Release Alt-Tab

move-cursor-on-preview.mp4

[tokyo4j]

Does applying this patch solve the problem?

diff --git a/src/input/cursor.c b/src/input/cursor.c
index ad5782e..3115522 100644
--- a/src/input/cursor.c
+++ b/src/input/cursor.c
@@ -506,6 +506,10 @@ cursor_get_resize_edges(struct wlr_cursor *cursor, struct cursor_context *ctx)
 static void
 process_cursor_motion(struct server *server, uint32_t time)
 {
+	if (server->osd_state.cycle_view) {
+		return;
+	}
+
 	/* If the mode is non-passthrough, delegate to those functions. */
 	if (server->input_mode == LAB_INPUT_STATE_MOVE) {
 		process_cursor_move(server, time);

[droc12345]

It's possible that during the preview, that if the window is minimized, when cycling through,
the system gets confused, or some internal state it's carrying gets inconsistent.
ie. the window is minimized but the system thinks it's not. I'll look at that later.

Edit to add: It's probably something in the way reparenting or resetting after OSD, is happening.
And when you do things like make all windows minimized (for example) it allows all windows
and parenting to be correct.

Consolatis would probably be better at looking at that, I think he wrote that section.

[Consolatis]

This indeed sounds like some race condition with the preview. Not quite sure what exactly, I'll try to look into this in the coming days. Thanks for the reproducer.

[tokyo4j]

I couldn't reproduce this issue when I tried @pablo-888's method for 5 minutes, after I applied my patch. That's so strange.

[pablo-888]

That's very weird indeed. I can pretty much reproduce it every time within a minute or less.

OP's problem seems to have gone away (?) I don't really care about previews so it's not a big deal. If nobody can reproduce it and Consolatis doesn't find anything whenever he looks into it then i'm cool with just closing this as previously intended/leaving it alone tbh 😁. Maybe nobody else ever runs into it who knows.

[Consolatis]

Maybe this happens when accidentally minimizing a window from the preview (e.g. if Alt is still held down)?

[tokyo4j]

After some debugging, I found this bug happens with procedure below:

1. Show preview of the minimized window by pressing Alt-Tab
2. Press the iconify button
3. Release Alt-Tab to finish OSD
4. Release the iconify button

EDIT: more precisely, 1 is press alt -> press tab -> release alt and 3 is release tab

Usually 3 comes before 2, but when repeating this procedure so fast, sometimes 3 comes after 2 and something wrong happens.

However, currently I have no idea why moving <mousebind button="Left" action="Press"> to <context name="TitleBar"> fixes this problem.

[charbelnicolas]

That's very weird indeed. I can pretty much reproduce it every time within a minute or less.

OP's problem seems to have gone away (?) I don't really care about previews so it's not a big deal. If nobody can reproduce it and Consolatis doesn't find anything whenever he looks into it then i'm cool with just closing this as previously intended/leaving it alone tbh 😁. Maybe nobody else ever runs into it who knows.

I was only able to reproduce it that one time and it has not happened to me again. I do have preview enabled on the window switcher.

[charbelnicolas]

Never mind I was able to reproduce it again just now on demand...

[charbelnicolas]

If I disable the preview on the window switcher it won't even switch to the window that is misbehaving.

Check the video below. Can you notice that when I switch windows the [xdg-shell] kitty charbel - rc.xml - NVIM window loses focus but still won't change to the other [xdg-shell] kitty ~ window?

If I switch between [xdg-shell] kitty charbel - rc.xml - NVIM and [xdg-shell] chromium Window... it works. It is only the [xdg-shell] kitty ~ window that has glitched out.

vid_2024_03_28_09_40_22.mp4

[charbelnicolas]

Mouse movement seems fine to me though.

I guess we need to disable <followMouse> when OSD is activated, as it has similar effects as <action name="Focus" /><action name="Raise" /> against minimized windows.

So the patch will look like:

diff --git a/src/input/cursor.c b/src/input/cursor.c
index eb359e7..cec9db2 100644
--- a/src/input/cursor.c
+++ b/src/input/cursor.c
@@ -529,7 +529,8 @@ process_cursor_motion(struct server *server, uint32_t time)
 		dnd_icons_move(seat, seat->cursor->x, seat->cursor->y);
 	}
 
-	if ((ctx.view || ctx.surface) && rc.focus_follow_mouse) {
+	if ((ctx.view || ctx.surface) && rc.focus_follow_mouse
+			&& !server->osd_state.cycle_view) {
 		desktop_focus_view_or_surface(seat, ctx.view, ctx.surface,
 			rc.raise_on_focus);
 	}

Yes, for sure it has something to do with <followMouse>. This is what I have on my config:

<focus>

	<followMouse>yes</followMouse>
	<followMouseRequiresMovement>yes</followMouseRequiresMovement>
	<raiseOnFocus>no</raiseOnFocus>

</focus>

[tokyo4j]

(Sorry I'm so slow at writing English and my last comment was not related to yours)

I think the video you posted doesn't contradict with what we've observed so far.

Can you apply this patch and see the problem still exists? If it does, maybe we're missing something.

[charbelnicolas]

vid_2024_03_28_10_11_44.mp4

[Consolatis]

The way to reproduce it is to minimize/iconify the window you want to glitch then bring up the window switcher with ALT-TAB and then move your cursor to the actual window being previewed so it gains focus and then let go of ALT (or whatever you have set up as modifier key).

Yes, for sure it has something to do with <followMouse>. This is what I have on my config:

<focus>
	<followMouse>yes</followMouse>
	<followMouseRequiresMovement>yes</followMouseRequiresMovement>
	<raiseOnFocus>no</raiseOnFocus>
</focus>

That appears to point to the focus action doing something weird in combination with the OSD preview of a minimized window (raiseOnFocus not being enabled).

not quite working

Edit:
I assume this could help as an additional safeguard:

diff --git a/src/desktop.c b/src/desktop.c
index 4141e974..2c5c8ecf 100644
--- a/src/desktop.c
+++ b/src/desktop.c
@@ -42,6 +42,12 @@ void
 desktop_focus_view(struct view *view, bool raise)
 {
 	assert(view);
+
+	/* Guard against accidental focus while the window switcher is open */
+	if (view->server->osd_state.cycle_view) {
+		return;
+	}
+
 	/*
 	 * Guard against views with no mapped surfaces when handling
 	 * 'request_activate' and 'request_minimize'.

Edit 2:
Actually.. that would break cycling completely because we also use it via end_cycling() in src/input/keyboard.c before resetting server->osd_state.cycle_view.

[Consolatis]

Mouse movement seems fine to me though.

I guess we need to disable <followMouse> when OSD is activated, as it has similar effects as <action name="Focus" /><action name="Raise" /> against minimized windows.

So the patch will look like:

diff --git a/src/input/cursor.c b/src/input/cursor.c
index eb359e7..cec9db2 100644
--- a/src/input/cursor.c
+++ b/src/input/cursor.c
@@ -529,7 +529,8 @@ process_cursor_motion(struct server *server, uint32_t time)
 		dnd_icons_move(seat, seat->cursor->x, seat->cursor->y);
 	}
 
-	if ((ctx.view || ctx.surface) && rc.focus_follow_mouse) {
+	if ((ctx.view || ctx.surface) && rc.focus_follow_mouse
+			&& !server->osd_state.cycle_view) {
 		desktop_focus_view_or_surface(seat, ctx.view, ctx.surface,
 			rc.raise_on_focus);
 	}

This looks good to me, combined with preventing the execution of mouse button actions when in A-Tab mode this should hopefully fix the issue.

[Consolatis]

I found another bug similar to this: we can still make the inconsistent state by activating the previewed window from wlr-foreign-toplevel-management clients like waybar:

Thanks, should be handled in the PR as well now.