[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69083: Emacs's keyboard hook state is not reset on session lock (Win
From: |
Eli Zaretskii |
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@mnet-mail.de>
> Cc: 69083@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.