GNU bug report logs - #17408
24.4.50; tooltips make ms-window go top

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17408 in the body.
You can then email your comments to 17408 AT debbugs.gnu.org in the normal way.

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

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; tooltips make ms-window go top
Date: Mon, 05 May 2014 15:40:41 +0200

I reproduce it on Windows 7, with today's trunk. But this is not new, I
just found a way to reproduce it, when the bucket of irritation overfilled.

1. Start "cmd"
2. From cmd do "runemacs -Q"
3. Arrange the windows so that cmd window is on top, but below is the
emacs window with toolbar visible.
4. Hover with mouse over toolbar button until tooltip appears.
5. Emacs windows goes top, covering cmd window. Cmd remains the active
app, you can type some letters to confirm that.

Expected behaviour: At 5 cmd window should stay on top, being fully
visible, not covered by Emacs window.

It's annoying when you accidentaly provoke the tooltip and bury your
application. Forgive me having Emacs always open and full screen :) It
happens with other tooltips too, for example tooltips in Occur buffer.

Fix suggestion: maybe tooltips should be supressed when Emacs is not the
active application.



In GNU Emacs 24.4.50.6 (i686-pc-mingw32)
 of 2014-05-05 on BONSOFTW7
Repository revision: 117061 rgm <at> gnu.org-20140505010854-t7blwdpa40ejp0xh
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=d:/program_files/emacs-master'

Configured features:
PNG NOTIFY ACL GNUTLS LIBXML2 ZLIB

Important settings:
  value of $LANG: pl
  locale-coding-system: cp1250

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<down-mouse-1> <mouse-1> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <down-mouse-1> <mouse-1> <help-echo> M-x
r e p o r <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32
ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32notify w32 multi-tty emacs)

Memory information:
((conses 8 78003 7556)
 (symbols 24 17728 0)
 (miscs 20 40 148)
 (strings 16 11985 4710)
 (string-bytes 1 307839)
 (vectors 8 9308)
 (vector-slots 4 372219 4670)
 (floats 8 59 178)
 (intervals 28 228 0)
 (buffers 508 12))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 17408 <at> debbugs.gnu.org
Subject: Re: bug#17408: 24.4.50; tooltips make ms-window go top
Date: Mon, 05 May 2014 16:56:01 +0300

> Date: Mon, 05 May 2014 15:40:41 +0200
> From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
> 
> I reproduce it on Windows 7, with today's trunk. But this is not new, I
> just found a way to reproduce it, when the bucket of irritation overfilled.
> 
> 1. Start "cmd"
> 2. From cmd do "runemacs -Q"
> 3. Arrange the windows so that cmd window is on top, but below is the
> emacs window with toolbar visible.
> 4. Hover with mouse over toolbar button until tooltip appears.
> 5. Emacs windows goes top, covering cmd window. Cmd remains the active
> app, you can type some letters to confirm that.
> 
> Expected behaviour: At 5 cmd window should stay on top, being fully
> visible, not covered by Emacs window.

I remember this behavior since I don't know when.  If someone knows
how to avoid it, explanations and/or patches are welcome.

> Fix suggestion: maybe tooltips should be supressed when Emacs is not the
> active application.

Thanks, but that's not a good suggestion, IMO.  For example, I
frequently work with Emacs windows that are in the background, and
have "focus follows mouse" set so that I could type into such windows.

In any case, when the mouse is inside an Emacs frame, Emacs gets a
Windows message about that, and it should process that message; it
cannot just disregard it.  So I don't see how your suggestion could
be implemented in practice.

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 17408 <at> debbugs.gnu.org
Subject: Re: bug#17408: 24.4.50; tooltips make ms-window go top
Date: Mon, 05 May 2014 16:19:42 +0200

> I
> frequently work with Emacs windows that are in the background, and
> have "focus follows mouse" set so that I could type into such windows.

And you would miss the tooltip so much? :)

> So I don't see how your suggestion could
> be implemented in practice.

My suggestion was to check whether the window is active right before 
displaying the tooltip. If the window is not active, the tooltip gets 
not displayed. Maybe the tooltip should still be displayed if "focus 
follows mouse" is set.

I don't see how this messes with your Emacs usage. Also don't know yet 
if it's feasible. But that's just a preliminary suggestion. If it gets 
accepted, it may be the simplest way to help the issue.

However Mozilla Thunderbird tooltips do not have this side effect. And 
sometimes Mozilla is even capable of supressing the incorrect Emacs 
behaviour. And I don't see its Mozilla's "create message" window be 
affected by Emacs. Yeah, this is not quite straighforward.

Jarek

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 17408 <at> debbugs.gnu.org
Subject: Re: bug#17408: 24.4.50; tooltips make ms-window go top
Date: Mon, 05 May 2014 17:47:02 +0300

> Date: Mon, 05 May 2014 16:19:42 +0200
> From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
> 
> > I
> > frequently work with Emacs windows that are in the background, and
> > have "focus follows mouse" set so that I could type into such windows.
> 
> And you would miss the tooltip so much? :)

Tooltips are a legitimate part of working with a frame.  I don't think
my personal preferences count in this matter.

> > So I don't see how your suggestion could
> > be implemented in practice.
> 
> My suggestion was to check whether the window is active right before 
> displaying the tooltip. If the window is not active, the tooltip gets 
> not displayed. Maybe the tooltip should still be displayed if "focus 
> follows mouse" is set.

What does that mean in practice?  How to determine whether a window
"is active" when it accepts Windows messages?

> I don't see how this messes with your Emacs usage. Also don't know yet 
> if it's feasible. But that's just a preliminary suggestion. If it gets 
> accepted, it may be the simplest way to help the issue.

I'd have to see the details to make up my mind.

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

From: Jarek Czekalski <jarek <at> jarek.katowice.pl>
To: 17408 <at> debbugs.gnu.org
Subject: Re: bug#17408: 24.4.50; tooltips make ms-window go top
Date: Mon, 05 May 2014 17:18:49 +0200

W dniu 2014-05-05 16:47, Eli Zaretskii pisze:
> What does that mean in practice? How to determine whether a window "is 
> active" when it accepts Windows messages? 

Active in sense of WM_ACTIVATEAPP message:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632614%28v=vs.85%29.aspx

Emacs could maintain app_is_active flag using this message.

Jarek

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarek <at> jarek.katowice.pl>
Cc: 17408 <at> debbugs.gnu.org
Subject: Re: bug#17408: 24.4.50; tooltips make ms-window go top
Date: Mon, 05 May 2014 18:42:36 +0300

> Date: Mon, 05 May 2014 17:18:49 +0200
> From: Jarek Czekalski <jarek <at> jarek.katowice.pl>
> 
> W dniu 2014-05-05 16:47, Eli Zaretskii pisze:
> > What does that mean in practice? How to determine whether a window "is 
> > active" when it accepts Windows messages? 
> 
> Active in sense of WM_ACTIVATEAPP message:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms632614%28v=vs.85%29.aspx
> 
> Emacs could maintain app_is_active flag using this message.

Patches are welcome, of course.

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 17408 <at> debbugs.gnu.org
Subject: bug#17408: 24.4.50; tooltips make ms-window go top
Date: Tue, 06 May 2014 16:46:37 +0200

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

Actually a complete solution was even easier. First I noticed that a 
Java app I use (muCommander) also retreats from displaying tooltips when 
the app is inactive. Then a Google search gave me this JDK bug report 
[1]. And once the SWP_NOOWNERZORDER flag was mentioned, the rest was a 
walk in a park.

Double checking what flags others use for their tooltips revealed 
nothing more, see this for example [3].

Attaching a patch that applies this flag to our tooltip SetWindowPos [2] 
invocations, in w32fns.c. Works for me. Tested on trunk and emacs24.

If you agree, I might commit this to emacs24.

Jarek

[1] http://bugs.java.com/view_bug.do?bug_id=6770457
[2] 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633545%28v=vs.85%29.aspx
[3] http://www.vtdev.com/net/tooltip.html

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 17408 <at> debbugs.gnu.org
Subject: Re: bug#17408: 24.4.50; tooltips make ms-window go top
Date: Tue, 06 May 2014 18:08:41 +0300

> Date: Tue, 06 May 2014 16:46:37 +0200
> From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
> 
> Actually a complete solution was even easier. First I noticed that a 
> Java app I use (muCommander) also retreats from displaying tooltips when 
> the app is inactive. Then a Google search gave me this JDK bug report 
> [1]. And once the SWP_NOOWNERZORDER flag was mentioned, the rest was a 
> walk in a park.
> 
> Double checking what flags others use for their tooltips revealed 
> nothing more, see this for example [3].
> 
> Attaching a patch that applies this flag to our tooltip SetWindowPos [2] 
> invocations, in w32fns.c. Works for me. Tested on trunk and emacs24.
> 
> If you agree, I might commit this to emacs24.

Looks good, thanks.  But please use the SWP_* flags explicitly, I see
no reason to define a special macro for 2 of them when all the rest
are spelled out.

Other than that, please go ahead and commit to emacs-24.

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

From: Jarek Czekalski <jarek <at> jarek.katowice.pl>
To: 17408 <at> debbugs.gnu.org
Subject: Re: bug#17408: 24.4.50; tooltips make ms-window go top
Date: Tue, 06 May 2014 17:26:34 +0200

Eli,

Thanks for the quick review.

> But please use the SWP_* flags explicitly, I see
> no reason to define a special macro for 2 of them when all the rest
> are spelled out.

There are 2 reasons:
1. 78 chars limit is exceeded and code looks worse without the macro. 
It's less readable and it's more difficult to say which flags change 
between invocations.
2. These 2 flags wrapped in a def are of constant nature, they must be 
used with every call to SetWindowPos. Those out of def are not used in 
all invocations and their presence depends on other parameters (size, 
origin).

I'm preparing to commit the version without macros, but if you're quick 
you can change your mind :)

Jarek

Message #34 received at 17408-done <at> debbugs.gnu.org (full text, mbox):

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 17408-done <at> debbugs.gnu.org
Subject: bug#17408: 24.4.50; tooltips make ms-window go top
Date: Tue, 06 May 2014 18:06:41 +0200

Applied as r117073 to emacs-24 branch [1]. Will be included in version 24.4.

http://bzr.savannah.gnu.org/lh/emacs/emacs-24/revision/117073

Previous Next

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