From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 07 08:39:03 2025 Received: (at submit) by debbugs.gnu.org; 7 Sep 2025 12:39:03 +0000 Received: from localhost ([127.0.0.1]:42996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvEff-0002Qo-5o for submit@debbugs.gnu.org; Sun, 07 Sep 2025 08:39:03 -0400 Received: from lists.gnu.org ([2001:470:142::17]:47660) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvEfQ-0002Ps-BW for submit@debbugs.gnu.org; Sun, 07 Sep 2025 08:38:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uvEfI-0005V9-T0 for bug-gnu-emacs@gnu.org; Sun, 07 Sep 2025 08:38:41 -0400 Received: from mail-out.m-online.net ([212.18.0.9]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uvEf0-0004ZT-4O for bug-gnu-emacs@gnu.org; Sun, 07 Sep 2025 08:38:36 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4cKV4026Btz1r5hN for ; Sun, 7 Sep 2025 14:38:08 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 4cKV400Rtqz1qqlS for ; Sun, 7 Sep 2025 14:38:08 +0200 (CEST) X-Virus-Scanned: amavis at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavis, port 10024) with ESMTP id ig8e2on3G9xz for ; Sun, 7 Sep 2025 14:37:58 +0200 (CEST) X-Auth-Info: uDeg5kWop26bC+zRwcwWMDg+2RcUpYxWTYsmaCV14v5vmEiWCXk9fVzuDa56MDnh Received: from Whiteflame (aftr-62-216-210-92.dynamic.mnet-online.de [62.216.210.92]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA for ; Sun, 7 Sep 2025 14:37:58 +0200 (CEST) From: Raffael Stocker To: bug-gnu-emacs@gnu.org Subject: 30.2; Windows: w32-notification-notify/-close handle frames incorrectly User-Agent: mu4e 1.12.8; emacs 30.2 X-Debbugs-Cc: Date: Sun, 07 Sep 2025 14:37:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=212.18.0.9; envelope-from=r.stocker@mnet-mail.de; helo=mail-out.m-online.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 =E2=80=98C-x 5 2=E2=80=99 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 ;; =E2=80=98w32-notification-notify=E2=80=99 ;; 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 =E2=80=98idf1=E2=80=99 and =E2=80=98idf2=E2=80=99 are always= 42. The problem is that =E2=80=98w32-notification-notify=E2=80=99 and =E2=80=98w32-notification-close=E2=80=99 use =E2=80=98SELECTED_FRAME()=E2= =80=99 to call the Windows API. This is fine for =E2=80=98-notify=E2=80=99, but not for =E2=80=98-close=E2= =80=99, which should instead pass the frame used in the corresponding call to =E2=80=98-notify=E2=80=99. I would suggest changing the ID returned in =E2=80=98w32-notification-notif= y=E2=80=99 to a cons cell containing ID and frame. While this breaks the API of these functions, with the usual pattern of =E2=80=98(let ((id (w32-notification-n= otify ...))) ...)=E2=80=99 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 07 09:47:41 2025 Received: (at 79400) by debbugs.gnu.org; 7 Sep 2025 13:47:42 +0000 Received: from localhost ([127.0.0.1]:43206 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvFk3-0006MW-Vm for submit@debbugs.gnu.org; Sun, 07 Sep 2025 09:47:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56660) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvFjw-0006KK-LQ for 79400@debbugs.gnu.org; Sun, 07 Sep 2025 09:47:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uvFjp-0002JF-Fi; Sun, 07 Sep 2025 09:47:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=W0ecARNXvvjHQO7nB7OU2q6b943e6lYo7zkguvrPgFs=; b=X3UUGgxSgC+v6G5JOfi4 facYAXUiyQJHbbaNDQdeZOt5aweYVNVreriSEZS8EzWM3rYGeuK+oESmCwEppyA7MKlu8fSfIsH5v fxPJsYJYUpCqEOBvu6n+IBFHL4ynOfV5Cgl1rBU6xhS+QZFDdaaSFuAm285O22RULDiANXUkuJRiX bMQMLDB/85FYOxFePpKhlIjfUObRjyqhxQdcKnKx8uGGS90YtaNLvtCpnOG3qB37Hfk1Q3OYfYNGB b6UOgMqULdq/jfHDWnBJqMuHekXzgLlu9TfwPpKHllhPy0Rj4t/kiLxYG0j+JRJ282KWCLVIL8CGQ iwY1LBYEqDpl9w==; Date: Sun, 07 Sep 2025 16:47:04 +0300 Message-Id: <864itee5nr.fsf@gnu.org> From: Eli Zaretskii To: Raffael Stocker In-Reply-To: (message from Raffael Stocker on Sun, 07 Sep 2025 14:37:54 +0200) Subject: Re: bug#79400: 30.2; Windows: w32-notification-notify/-close handle frames incorrectly References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79400 Cc: 79400@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Raffael Stocker > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 07 10:30:03 2025 Received: (at 79400) by debbugs.gnu.org; 7 Sep 2025 14:30:03 +0000 Received: from localhost ([127.0.0.1]:44905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvGP0-0000m0-0e for submit@debbugs.gnu.org; Sun, 07 Sep 2025 10:30:03 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:57529) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvGOt-0000lg-6w for 79400@debbugs.gnu.org; Sun, 07 Sep 2025 10:29:52 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4cKXXr4hVZz1sClx; Sun, 7 Sep 2025 16:29:48 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 4cKXXr2lPLz1qqlY; Sun, 7 Sep 2025 16:29:48 +0200 (CEST) X-Virus-Scanned: amavis at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavis, port 10024) with ESMTP id RcahB-oGAk2z; Sun, 7 Sep 2025 16:29:38 +0200 (CEST) X-Auth-Info: UfmiomUleWVxR0IWDj0SXgYwg+/rzFGTHeKg0gAHT6H80+nFx8fFA5bv+xjHg9t8 Received: from Whiteflame (aftr-62-216-210-92.dynamic.mnet-online.de [62.216.210.92]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Sun, 7 Sep 2025 16:29:38 +0200 (CEST) From: Raffael Stocker To: Eli Zaretskii Subject: Re: bug#79400: 30.2; Windows: w32-notification-notify/-close handle frames incorrectly In-Reply-To: <864itee5nr.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 07 Sep 2025 16:47:04 +0300") References: <864itee5nr.fsf@gnu.org> User-Agent: mu4e 1.12.8; emacs 30.2 Date: Sun, 07 Sep 2025 16:29:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79400 Cc: 79400@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> The problem is that =E2=80=98w32-notification-notify=E2=80=99 and >> =E2=80=98w32-notification-close=E2=80=99 use =E2=80=98SELECTED_FRAME()= =E2=80=99 to call the Windows API. >> This is fine for =E2=80=98-notify=E2=80=99, but not for =E2=80=98-close= =E2=80=99, which should instead >> pass the frame used in the corresponding call to =E2=80=98-notify=E2=80= =99. > > 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 =E2=80=98w32-notification-no= tify=E2=80=99 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 =E2=80=98add_tray_notification=E2=80=99 and =E2=80=98delete_tray_notification=E2=80=99. These functions use the frame = to obtain the window handle, but also to do some basic sanity check using =E2=80=98FRAME_W32_P=E2=80=99. I'm not sure something like this can be don= e if we pass the window handle directly. Regards, Raffael