GNU bug report logs - #69083
Emacs's keyboard hook state is not reset on session lock (Windows)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Raffael Stocker <r.stocker <at> mnet-mail.de>
Cc: 69083 <at> debbugs.gnu.org
Subject: bug#69083: Emacs's keyboard hook state is not reset on session lock (Windows)
Date: Wed, 21 Feb 2024 14:37:46 +0200

> From: Raffael Stocker <r.stocker <at> mnet-mail.de>
> Cc: 69083 <at> debbugs.gnu.org
> Date: Tue, 20 Feb 2024 19:51:21 +0100
> 
> I experimented a bit today and found that the remove_w32_kbdhook
> function is not actually getting called when Emacs is being killed.  It
> is only called when the Emacs window receives a WM_DESTROY message.  But
> we get relevant WM_* messages, when
> 
>    - creating second frame with ‘C-x 5 2’ and closing it using ‘C-x 5 0’:
>      WM_EMACS_DESTROYWINDOW, then WM_DESTROY
>    - creating second frame with ‘C-x 5 2’ and closing it by clicking ‘X’
>      in frame decoration:
>      WM_CLOSE, then WM_EMACS_DESTROYWINDOW, then WM_DESTROY
>    - closing the last frame by clicking ‘X’ in frame decoration: WM_CLOSE
>    - killing Emacs with ‘C-x C-c’: nothing
> 
> At least, if Emacs is not run as daemon.  Then, the WM_DESTROY is only
> handled when there is still another frame, and in this case
> ‘remove_w32_kbdhook’ will not remove the hook as kbdhook.hook_count > 1.
> 
> If Emacs is run as daemon, it cleans up the keyboard hook when closing
> the last window.
> 
> Is there a better place where the remove_w32_kbdhook call could go such
> that cleanup can always happen?

I think that place is term_ntproc.

> > This URL:
> >
> >   https://stackoverflow.com/questions/8606300/how-to-detect-windows-is-locked
> >
> > seems to indicate that WTSRegisterSessionNotification requires
> > elevation on Windows 10/11.  Did you get the UAC prompt when calling
> > that API?  Are you running with admin privileges when you test this
> > code?  Triggering UAC prompts when starting Emacs would be a nuisance
> > to our users.
> 
> I have read this post, but it seems to be wrong.  I don't have any
> elevated privileges and it works without showing any prompt, at least on
> Windows 10.  I'll try to have my colleague test it as well, she runs
> Windows 11.

Is your user a member of the local Administrators group?  Did you try
running this code as a "normal" user, not an admin?

> >> Unfortunately, this didn't work for me.  I tried calling
> >> ‘EnumWindows(find_child_console, ...)’ with a ‘child_process’ instance
> >> containing the current process id as returned by ‘GetCurrentProcessId’,
> >> but I don't seem to get a useful window handle.
> >
> > What do you mean?  What is the result of using find_child_console?
> > does the condition in find_child_console, which looks at the
> > process_id of all windows, never match the process ID of the Emacs
> > session running with -nw?  Or what else goes wrong?
> 
> I'm not quite sure myself what I mean.  I will experiment with this
> a bit more and try to find out what's happening.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.