GNU bug report logs - #6372
24.0.50; C-mouse-1 activates region on Windows

Previous Next

To reply to this bug, email your comments to 6372 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: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50; C-mouse-1 activates region
Date: Mon, 7 Jun 2010 10:19:44 -0700

emacs -Q
 
1. Click C-mouse-1. The Buffer Menu opens.
 
2. Click mouse-1 outside the menu. The menu disappears, which is
correct.
 
But the region is activated, which is incorrect.  Clicking mouse-1 here
should simply set point, without activating the region.
 

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-05-23 on G41R2F1
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include'
 

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

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 6372 <at> debbugs.gnu.org
Subject: Re: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Sun, 08 Jul 2012 21:41:18 +0800

"Drew Adams" <drew.adams <at> oracle.com> writes:

> 1. Click C-mouse-1. The Buffer Menu opens.
>  
> 2. Click mouse-1 outside the menu. The menu disappears, which is
> correct.
>  
> But the region is activated, which is incorrect.  Clicking mouse-1 here
> should simply set point, without activating the region.

FWIW, this is not reproducible on GNU/Linux.  Maybe a Windows-only
issue; can someone with access to Windows check if this still happens?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: cyd <at> gnu.org
Cc: 6372 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Sun, 08 Jul 2012 19:00:13 +0400

Chong Yidong <cyd <at> gnu.org> writes:

> "Drew Adams" <drew.adams <at> oracle.com> writes:
>
>> 1. Click C-mouse-1. The Buffer Menu opens.
>>
>> 2. Click mouse-1 outside the menu. The menu disappears, which is
>> correct.
>>
>> But the region is activated, which is incorrect.  Clicking mouse-1 here
>> should simply set point, without activating the region.
>
> FWIW, this is not reproducible on GNU/Linux.  Maybe a Windows-only
> issue; can someone with access to Windows check if this still happens?

It does happen.

And if I ctrl-click mouse-1 when the menu if open, minibuffer says
"<C-drag-mouse-1> is undefined", so looks like doing mouse-1 click when
the menu is open is registered as drag-mouse-1 event.
(I tried it in Ubuntu on an older Emacs 24 build, and that didn't happen
either).

In GNU Emacs 24.1.50.1 (i386-mingw-nt6.1.7601) of 2012-07-06.

--Dmitry

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 6372 <at> debbugs.gnu.org
Subject: RE: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Sun, 8 Jul 2012 10:18:40 -0700

> "Drew Adams" <drew.adams <at> oracle.com> writes:
> 
> > 1. Click C-mouse-1. The Buffer Menu opens.
> >  
> > 2. Click mouse-1 outside the menu. The menu disappears, which is
> > correct.
> >  
> > But the region is activated, which is incorrect.  Clicking 
> > mouse-1 here should simply set point, without activating the region.
> 
> FWIW, this is not reproducible on GNU/Linux.  Maybe a Windows-only
> issue; can someone with access to Windows check if this still happens?

Yes, the bug is still there.

I just checked in this build:

In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-07-01 on MARVIN
Bzr revision: 108826 yamaoka <at> jpl.org-20120702004841-kzatmydft6dct0ry
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

emacs -Q

`C-mouse-1'

Move mouse outside the popped up menu, and so that some text is between the
first click and the next.

`mouse-1'

The text between the first and second clicks is selected (active region).

Thx.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 6372 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: Re: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Sun, 08 Jul 2012 21:09:38 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Sun, 8 Jul 2012 10:18:40 -0700
> Cc: 6372 <at> debbugs.gnu.org
> 
> > "Drew Adams" <drew.adams <at> oracle.com> writes:
> > 
> > > 1. Click C-mouse-1. The Buffer Menu opens.
> > >  
> > > 2. Click mouse-1 outside the menu. The menu disappears, which is
> > > correct.
> > >  
> > > But the region is activated, which is incorrect.  Clicking 
> > > mouse-1 here should simply set point, without activating the region.
> > 
> > FWIW, this is not reproducible on GNU/Linux.  Maybe a Windows-only
> > issue; can someone with access to Windows check if this still happens?
> 
> Yes, the bug is still there.

Indeed.  After the recipe, "C-h l" shows this:

  <C-down-mouse-1> <drag-mouse-1> C-h l

What do you see on GNU/Linux?  Which toolkit(s) did you try it with?

FWIW, in the MSDOS build the problem doesn't happen, and view-lossage
shows just this:

  <C-down-mouse-1> C-h l

Any clue where could drag-mouse-1 come from?  I guess we don't discard
some events that we should.

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

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6372 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Mon, 09 Jul 2012 12:37:05 +0800

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

> Indeed.  After the recipe, "C-h l" shows this:
>
>   <C-down-mouse-1> <drag-mouse-1> C-h l
>
> What do you see on GNU/Linux?  Which toolkit(s) did you try it with?
>
> FWIW, in the MSDOS build the problem doesn't happen, and view-lossage
> shows just this:
>
>   <C-down-mouse-1> C-h l
>
> Any clue where could drag-mouse-1 come from?  I guess we don't discard
> some events that we should.

On GNU/Linux (both GTK build and Lucid build) I see

  <C-down-mouse-1> C-h l

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 6372 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Sat, 21 Jul 2012 14:42:06 +0300

> From: Chong Yidong <cyd <at> gnu.org>
> Cc: Drew Adams <drew.adams <at> oracle.com>,  6372 <at> debbugs.gnu.org
> Date: Mon, 09 Jul 2012 12:37:05 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Indeed.  After the recipe, "C-h l" shows this:
> >
> >   <C-down-mouse-1> <drag-mouse-1> C-h l
> >
> > What do you see on GNU/Linux?  Which toolkit(s) did you try it with?
> >
> > FWIW, in the MSDOS build the problem doesn't happen, and view-lossage
> > shows just this:
> >
> >   <C-down-mouse-1> C-h l
> >
> > Any clue where could drag-mouse-1 come from?  I guess we don't discard
> > some events that we should.
> 
> On GNU/Linux (both GTK build and Lucid build) I see
> 
>   <C-down-mouse-1> C-h l

Thanks.

I'm sorry, but it will take someone who knows more than I do about
MS-Windows messages and their processing to fix this one.  I describe
my findings below in the hope that someone will pick up where I left
off.

We track mouse events during pop-up menu by sending the
WM_EMACS_TRACKPOPUPMENU message to the Emacs message pump.  This
message is handled by w32_wnd_proc around line 3770 of w32fns.c.
There, we call TrackPopupMenu, a Windows API that displays the menu
and returns the user selection of menu items.  After TrackPopupMenu
returns, we remove any mouse events still in the message queue, by
calling PeekMessage with appropriate arguments, and return the user
selection to our caller, which is w32_menu_show.  The user selection
returned is zero when the user closes the menu without selecting any
item, by clicking outside the menu.  w32_menu_show then removes any
mouse events in the Emacs event queue by calling discard_mouse_events.

What happens in this case, and is the reason for the bug, is that
somehow the mouse click event that pops down the menu is not delivered
to Emacs until _after_ w32_menu_show returns.  That click is not
removed by PeekMessage mentioned above, and is not discarded by
discard_mouse_events.  It is read by w32_wnd_proc only after all of
the above processing is complete, and any memory of the menu that was
popped down is gone.  So Emacs processes that mouse click as a normal
event, oblivious to the fact that it actually happened as part of the
menu.

What I don't understand here is why that mouse click is not delivered
when we call PeekMessage, so that it could be discarded.  It's as if
Windows withholds that message from being put into the Emacs message
queue.  Why is that, and what can we do to be able to peek at that
click message as part of menu processing and discard it, is beyond me.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>, "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 6372 <at> debbugs.gnu.org
Subject: RE: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Wed, 8 Aug 2012 11:39:17 -0700

ping.

> From: Eli Zaretskii Sent: Saturday, July 21, 2012 4:42 AM
> I'm sorry, but it will take someone who knows more than I do about
> MS-Windows messages and their processing to fix this one.  I describe
> my findings below in the hope that someone will pick up where I left
> off.
> 
> We track mouse events during pop-up menu by sending the
> WM_EMACS_TRACKPOPUPMENU message to the Emacs message pump.  This
> message is handled by w32_wnd_proc around line 3770 of w32fns.c.
> There, we call TrackPopupMenu, a Windows API that displays the menu
> and returns the user selection of menu items.  After TrackPopupMenu
> returns, we remove any mouse events still in the message queue, by
> calling PeekMessage with appropriate arguments, and return the user
> selection to our caller, which is w32_menu_show.  The user selection
> returned is zero when the user closes the menu without selecting any
> item, by clicking outside the menu.  w32_menu_show then removes any
> mouse events in the Emacs event queue by calling discard_mouse_events.
> 
> What happens in this case, and is the reason for the bug, is that
> somehow the mouse click event that pops down the menu is not delivered
> to Emacs until _after_ w32_menu_show returns.  That click is not
> removed by PeekMessage mentioned above, and is not discarded by
> discard_mouse_events.  It is read by w32_wnd_proc only after all of
> the above processing is complete, and any memory of the menu that was
> popped down is gone.  So Emacs processes that mouse click as a normal
> event, oblivious to the fact that it actually happened as part of the
> menu.
> 
> What I don't understand here is why that mouse click is not delivered
> when we call PeekMessage, so that it could be discarded.  It's as if
> Windows withholds that message from being put into the Emacs message
> queue.  Why is that, and what can we do to be able to peek at that
> click message as part of menu processing and discard it, is beyond me.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 6372 <at> debbugs.gnu.org
Subject: RE: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Sun, 16 Sep 2012 16:34:36 -0700

ping

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 6372 <at> debbugs.gnu.org
Subject: RE: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Fri, 19 Oct 2012 08:02:58 -0700

ping

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 6372 <at> debbugs.gnu.org
Subject: Re: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Tue, 18 Aug 2020 11:10:33 +0000

"Drew Adams" <drew.adams <at> oracle.com> writes:

> emacs -Q
>
> 1. Click C-mouse-1. The Buffer Menu opens.
>
> 2. Click mouse-1 outside the menu. The menu disappears, which is
> correct.
>
> But the region is activated, which is incorrect.  Clicking mouse-1 here
> should simply set point, without activating the region.
>
>
> In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
>  of 2010-05-23 on G41R2F1
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include'

That was more than 10 years ago.

I can't reproduce this on GNU/Linux, but from the discussion this looked
like a Windows-specific bug.

Since this was such a long time ago, I just wanted to ask if you (or
anyone else) can still reproduce this?  Thanks.

Best regards,
Stefan Kangas

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 6372 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Tue, 18 Aug 2020 15:11:03 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Tue, 18 Aug 2020 11:10:33 +0000
> Cc: 6372 <at> debbugs.gnu.org
> 
> > emacs -Q
> >
> > 1. Click C-mouse-1. The Buffer Menu opens.
> >
> > 2. Click mouse-1 outside the menu. The menu disappears, which is
> > correct.
> >
> > But the region is activated, which is incorrect.  Clicking mouse-1 here
> > should simply set point, without activating the region.
> >
> >
> > In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
> >  of 2010-05-23 on G41R2F1
> > Windowing system distributor `Microsoft Corp.', version 5.1.2600
> > configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include'
> 
> That was more than 10 years ago.
> 
> I can't reproduce this on GNU/Linux, but from the discussion this looked
> like a Windows-specific bug.
> 
> Since this was such a long time ago, I just wanted to ask if you (or
> anyone else) can still reproduce this?  Thanks.

I still see it, yes.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: 6372 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: RE: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Tue, 18 Aug 2020 09:37:49 -0700 (PDT)

> I still see it, yes.

I do too.

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

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: 6372 <at> debbugs.gnu.org.
Subject: RE: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Fri, 16 Aug 2024 03:18:42 +0200

[Message part 1 (text/plain, inline)]

This seems to happen because TrackPopupMenu returns as
soon as the WM_LBUTTONDOWN is received. That message is
correctly purged. The problem comes from the subsequent
WM_LBUTTONUP message.

This patch is not a clean solution, but keeps the problem local.

[patch.diff (text/plain, attachment)]

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

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 6372 <at> debbugs.gnu.org.
Subject: Re: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Sun, 18 Aug 2024 22:47:09 +0100

Cecilio Pardo <cpardo <at> imayhem.com> writes:

> This seems to happen because TrackPopupMenu returns as
> soon as the WM_LBUTTONDOWN is received. That message is
> correctly purged. The problem comes from the subsequent
> WM_LBUTTONUP message.
>
> This patch is not a clean solution, but keeps the problem local.
>
>
>
> [2. text/plain; patch.diff]...

To confirm, is the bug report related to 24.0.50, a rather old version?

Have you checked if this bug is present in a recent version of Emacs?

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

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Jeremy Bryant <jb <at> jeremybryant.net>
Cc: 6372 <at> debbugs.gnu.org.
Subject: Re: bug#6372: 24.0.50; C-mouse-1 activates region
Date: Mon, 19 Aug 2024 09:11:44 +0200

[Message part 1 (text/plain, inline)]

On 18/08/2024 23:47, Jeremy Bryant wrote:
>
>> This seems to happen because TrackPopupMenu returns as
>> soon as the WM_LBUTTONDOWN is received. That message is
>> correctly purged. The problem comes from the subsequent
>> WM_LBUTTONUP message.
>>
>> This patch is not a clean solution, but keeps the problem local.
>>
>>
>>
>> [2. text/plain; patch.diff]...
> To confirm, is the bug report related to 24.0.50, a rather old version?
>
> Have you checked if this bug is present in a recent version of Emacs?

Yes, it is present in current version.

[Message part 2 (text/html, inline)]

Previous Next

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