bug#69083: closed (Emacs's keyboard hook state is not reset on session lock (Windows))

[GNU bug Tracking System]

Your message dated Thu, 14 Mar 2024 10:25:07 +0200
with message-id <86il1pb4po.fsf@gnu.org>
and subject line Re: bug#69083: Emacs's keyboard hook state is not reset on 
session lock (Windows)
has caused the debbugs.gnu.org bug report #69083,
regarding Emacs's keyboard hook state is not reset on session lock (Windows)
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
69083: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69083
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: Emacs's keyboard hook state is not reset on session lock (Windows) Date: Mon, 12 Feb 2024 20:04:50 +0100 User-agent: mu4e 1.10.8; emacs 29.2

Hi,

when locking the computer using WIN+L on Windows, Emacs is supposed to
reset its keyboard hook state.  This is done in the function
‘reset_w32_kbdhook_state’ in ‘w32fns.c’, which is called upon receiving
the ‘WM_WTSSESSION_CHANGE’ message with the ‘WTS_SESSION_LOCK’
parameter.  However, this message is never received, because to receive
it, an application must register for session notifications, which Emacs
doesn't do.

When Emacs can't reset its state, the handling of the windows key is
confused after locking and unlocking the computer, but the issue seems
to auto-correct when a windows key is pressed again.  I didn't observe
any real problem with it, but I have not configured any non-default
handling of the windows keys in Emacs.  It may be different in those
cases.

Note that while this bug looks like it might be connected to bug#68914,
I believe it's a separate issue.  The behaviour described there is
neither triggered by this bug nor solved by the attached patch.

The attached patch rectifies the situation, but to do so, Emacs must be
linked with ‘wtsapi32.dll’.  I am not sure whether there is a different
way of resetting the state that doesn't require the introduction of a
new dependency.

To receive session notifications, one must provide a window handle,
which is fine if Emacs does not run in console mode.  I don't know
whether it is possible to get these notifications in console Emacs; at
least using the console handle didn't work for me.

I also noticed that while the keyboard hook is set up in console mode
using ‘setup_w32_kbdhook’, there does not seem to be a corresponding
call to ‘remove_w32_kbdhook’.  Also, in console mode the keyboard hook
is always installed, while in GUI Emacs it is only installed when
‘WINDOWSNT’ is defined.

I have zero experience in Windows programming, so it would be highly
desirable if someone with more knowledge could comment on the issue and
my proposed solution.

Regards,
Raffael

reset_kbdhook.patch
Description: session notification patch

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#69083: Emacs's keyboard hook state is not reset on session lock (Windows)
>
>
>
>
> Date: 
>
> Thu, 14 Mar 2024 10:25:07 +0200
>
>
>
>
> > From: Raffael Stocker <r.stocker@mnet-mail.de>
> > Cc: 69083@debbugs.gnu.org
> > Date: Mon, 04 Mar 2024 19:10:33 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > >> The order is not important, I just didn't know where to look to get
> > >> a frame; sorry for the noise.  I now use ‘Fnext_frame’.
> > >
> > > Unfortunately, I don't think you cannot use Fnext_frame here.  The
> > > function which calls it, w32_wnd_proc, runs in a separate thread, so
> > > it generally cannot access Lisp objects safely.  However, it is okay
> > > to traverse the list of the frames, as w32_window_to_frame does, see
> > > the comment at the beginning of w32_wnd_proc.  So I think you could
> > > use a similar loop with FOR_EACH_FRAME, and use some frame from there,
> > > perhaps the first one?
> > >
> > > Alternatively, and maybe more safely, you could call
> > > maybe_pass_notification from w32_destroy_window, which is called from
> > > the main (a.k.a. "Lisp") thread, so then you can use Fnext_frame
> > > (actually, I would make next_frame extern instead of static and call
> > > it directly).  This means the notifications are passed a bit before
> > > the frame is actually deleted by the OS, but I think this is okay?
> > 
> > I went with the first option, using FOR_EACH_FRAME, because I am not
> > sure about the safety of modifying the kbdhook struct from the other
> > thread.
>
> Thanks.  I needed to fix this in small ways, to get it to compile with
> mingw.org's MinGW, and I've now installed the results on the master
> branch.
>
> With that, I'm closing this bug.
>
>
> --- End Message ---