Re: [hackers] Re: [dwm][PATCH] manage: disable fullscreen on the old window when a new window is opened

From: Ruben Gonzalez <neorubenx_AT_gmail.com>
Date: Fri, 3 Apr 2026 17:47:10 +0300

Thanks NKR & vally for the replies.

Yes, support for lockfullscreen would have to be added, which is
simple in this case, but as you mentioned, there's no clear consensus
on how it should behave. As NKR said, the ideal thing would be to see
if there are any exact specifications from (xdg/icccm/ewmh) or what
other window managers generally do in these cases. But if there
haven't been many complaints so far, there's no need to worry, since I
only encountered this behavior by chance, and I certainly didn't
expect it to behave that way. :)

Thanks again!

On Fri, Mar 27, 2026 at 10:38 PM vally <vallyyyyy_AT_proton.me> wrote:
>
> Hi,
>
> I can reproduce this in mpv & vidya.
>
> The patch doesn't respect lockfullscreen in config.def.h (and by extension
> fakefullscreen), and I more wanted to talk about the unfocus() in there.
>
> As NRK hints, In manage(), should unfocus() not be guarded with tests on
> isfullscreen and lockfullscreen, because that would agree with focusstack on the
> handling of a fullscreen clients' focus (67d76bdc)? That is you don't unfocus
> the client, if isfullscreen && lockfullscreen, just like you bail out of
> focusstack() (same thing). I say there is already this precedent in dwm.c, let
> alone another WM.
>
> If lockfullscreen is not set, focusstack() assumes that it makes sense to take
> focus off of a fullscreen client, so the unfocus() in manage is okay in that case
> (i.e. you can assume that a "visually nothing happens" situation, does not
> happen).
>
> That behavior does the right thing for base dwm and dwm+fakefullscreen. Does
> anyone else set it to 0 for some other purpose?
>
> 67d76bdc: Do not allow focus to drift from fullscreen client
> 138b405f: lockfullscreen
>
> Regards
>
>
> On 27/03/2026 12:02, Ruben Gonzalez wrote:
> > Hello,
> >
> > What do you think about this issue/patch? Can you reproduce it?
> >
> > Regards!
> >
> > On Sat, Mar 14, 2026 at 3:53 AM Ruben Gonzalez <neorubenx_AT_gmail.com> wrote:
> >>
> >> When a new window is managed (spawned), it becomes the focused client.
> >> But, If the previously focused window was in fullscreen mode, it
> >> remains fullscreen and completely covers the new window, leading to
> >> "invisible focus" where the user types into an invisible terminal.
> >>
> >> Steps to reproduce:
> >> 1. Open a terminal (terminal A) and make the terminal fullscreen.
> >> 2. Open a new terminal B (Mod+Shift+Enter)
> >> 3. You can see that visually nothing happens; terminal A is still fullscreen.
> >> 4. Try tying the command touch /tmp/foo.txt (you will see nothing in terminal A)
> >> 5. Exit fullscreen on the current terminal A.
> >> 6. You will see that the command "touch" was received and executed by
> >> the new terminal B.
> >>
> >> This fix ensures that the fullscreen state is removed from the
> >> previously focused window when a new client is managed on the same
> >> monitor, keeping the new window visible.
> >>
> >> From 38de8cc3233ffaae88f2e6c3071978c728bd5d7b Mon Sep 17 00:00:00 2001
> >> From: Ruben Gonzalez <gonzaru_AT_sdf.org>
> >> Date: Sat, 14 Mar 2026 03:12:04 +0200
> >> Subject: [PATCH] manage: disable fullscreen on the old window when a new
> >> window is opened
> >>
> >> ---
> >> dwm.c | 5 ++++-
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/dwm.c b/dwm.c
> >> index ab3a84c..54812dc 100644
> >> --- a/dwm.c
> >> +++ b/dwm.c
> >> _AT_@ -1080,8 +1080,11 @@ manage(Window w, XWindowAttributes *wa)
> >> (unsigned char *) &(c->win), 1);
> >> XMoveResizeWindow(dpy, c->win, c->x + 2 * sw, c->y, c->w, c->h);
> >> /* some windows require this */
> >> setclientstate(c, NormalState);
> >> - if (c->mon == selmon)
> >> + if (c->mon == selmon) {
> >> + if (selmon->sel && selmon->sel->isfullscreen)
> >> + setfullscreen(selmon->sel, 0);
> >> unfocus(selmon->sel, 0);
> >> + }
> >> c->mon->sel = c;
> >> arrange(c->mon);
> >> XMapWindow(dpy, c->win);
> >> --
> >> 2.43.0
> >
>
>
>
Received on Fri Apr 03 2026 - 16:47:10 CEST

This archive was generated by hypermail 2.3.0 : Fri Apr 03 2026 - 17:24:37 CEST