GNU bug report logs - #79400
30.2; Windows: w32-notification-notify/-close handle frames incorrectly

Previous Next

To reply to this bug, email your comments to 79400 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Raffael Stocker <r.stocker <at> mnet-mail.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.2; Windows: w32-notification-notify/-close handle frames
 incorrectly
Date: Sun, 07 Sep 2025 14:37:54 +0200

Hi Emacs,

notifications on Windows are implemented incorrectly in the sense that
the implementation assumes that notifications are per process, when in
fact they are per frame.  This causes a bug that doesn't allow a
notification sent from one frame to be closed from another.  To
reproduce:

--8<---------------cut here---------------start------------->8---
$ emacs -Q
;; call the first frame "F1" and evaluate:
(setq idf1 (w32-notification-notify :title "F1" :body "Hailing from F1!"))
-> 42

;; a notification is shown

;; now ‘C-x 5 2’ to create another frame "F2" and evaluate:
(w32-notification-close idf1)
nil

;; the notification persists

;; from frame F2, evaluate:
(setq idf2 (w32-notification-notify :title "F2" :body "Hailing from F2!"))
-> 42

;; another notification is shown, contradicting the documentation of
;; ‘w32-notification-notify’

;; from frame F1, attempt to close the second notification by evaluating:

(w32-notification-close idf2)
nil

;; this closes the *first* notification, the second one persists

;; from frame F2, you can close the second notification by evaluating
;; any of:

(w32-notification-close idf1)
;; or
(w32-notification-close idf2)
--8<---------------cut here---------------end--------------->8---

Note that both ‘idf1’ and ‘idf2’ are always 42.

The problem is that ‘w32-notification-notify’ and
‘w32-notification-close’ use ‘SELECTED_FRAME()’ to call the Windows API.
This is fine for ‘-notify’, but not for ‘-close’, which should instead
pass the frame used in the corresponding call to ‘-notify’.

I would suggest changing the ID returned in ‘w32-notification-notify’ to
a cons cell containing ID and frame.  While this breaks the API of these
functions, with the usual pattern of ‘(let ((id (w32-notification-notify
...))) ...)’ this should not be a problem for Lisp code.

The relevance for the user is that sometimes, when several frames are
open, notifications don't get closed and new ones may not be shown, for
apparently no reason.

Regards,
Raffael

Message #8 received at 79400 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Raffael Stocker <r.stocker <at> mnet-mail.de>
Cc: 79400 <at> debbugs.gnu.org
Subject: Re: bug#79400: 30.2;
 Windows: w32-notification-notify/-close handle frames incorrectly
Date: Sun, 07 Sep 2025 16:47:04 +0300

> From: Raffael Stocker <r.stocker <at> mnet-mail.de>
> Date: Sun, 07 Sep 2025 14:37:54 +0200
> 
> The problem is that ‘w32-notification-notify’ and
> ‘w32-notification-close’ use ‘SELECTED_FRAME()’ to call the Windows API.
> This is fine for ‘-notify’, but not for ‘-close’, which should instead
> pass the frame used in the corresponding call to ‘-notify’.

What if that frame no longer exists?

> I would suggest changing the ID returned in ‘w32-notification-notify’ to
> a cons cell containing ID and frame.

Why not return an integer that is the handle of the frame's w32 window
instead?

Thanks.

Message #11 received at 79400 <at> debbugs.gnu.org (full text, mbox):

From: Raffael Stocker <r.stocker <at> mnet-mail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79400 <at> debbugs.gnu.org
Subject: Re: bug#79400: 30.2; Windows: w32-notification-notify/-close handle
 frames incorrectly
Date: Sun, 07 Sep 2025 16:29:38 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> The problem is that ‘w32-notification-notify’ and
>> ‘w32-notification-close’ use ‘SELECTED_FRAME()’ to call the Windows API.
>> This is fine for ‘-notify’, but not for ‘-close’, which should instead
>> pass the frame used in the corresponding call to ‘-notify’.
>
> What if that frame no longer exists?

In that case, Windows seems to close the notification by itself.  Last
time I checked, the icon in the task bar remained, but on mouse-over it
also vanished.

>> I would suggest changing the ID returned in ‘w32-notification-notify’ to
>> a cons cell containing ID and frame.
>
> Why not return an integer that is the handle of the frame's w32 window
> instead?

Do you mean besides the ID or instead of the ID?

Instead of the ID: if the ID ever takes on a value besides 42 or Windows
allows more than one notification per frame, we have the same problem
all over again.

Besides the ID: it could be the window handle, which would require
changes (simplifications?) to ‘add_tray_notification’ and
‘delete_tray_notification’.  These functions use the frame to obtain the
window handle, but also to do some basic sanity check using
‘FRAME_W32_P’.  I'm not sure something like this can be done if we pass
the window handle directly.

Regards,
Raffael

Previous Next

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