bug#34819: 26.1; Blank help-echo tooltips for mode line menus

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Phil Sainty]

Following from:
https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00324.html

Recipe from emacs -Q (and --with-x-toolkit=lucid)

* M-x text-mode
* Mouse 1 click on "Text" in the mode line to open the menu
* Hover over any of the menu items until the tooltip appears

For me, this produces tooltips of the appropriate dimensions, but the
text itself is not visible.

When I use the top menu bar instead of the mode line, the tooltip text
is visible.

I note also that if I simply hover over "Text" in the mode line, the
"Major mode" tooltip appears with visible text; however if I click-and-
hold the mouse button *before* the tooltip has had time to appear, then
it will be blank when it does appear (over the top of the menu).


-Phil




In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll 
bars)
  of 2018-10-23 built on hal
Windowing system distributor 'The X.Org Foundation', version 
11.0.11906000
System Description:	Ubuntu 18.04.2 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
(New file)
Using vacuous schema
Quit [2 times]
Configured using:
  'configure --prefix=/home/phil/emacs/26/26.1/usr/local
  --with-x-toolkit=lucid --without-sound'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK DBUS GSETTINGS NOTIFY GNUTLS
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 THREADS LCMS2

Important settings:
   value of $LANG: en_NZ.UTF-8
   locale-coding-system: utf-8-unix

Major mode: nXML

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils rng-xsd xsd-regexp rng-cmpct rng-nxml
rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util
rng-pttrn nxml-ns easymenu nxml-mode nxml-outln nxml-rap sgml-mode seq
byte-opt gv bytecomp byte-compile cconv dom cl-loaddefs cl-lib nxml-util
nxml-enc xmltok dired dired-loaddefs advice elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded 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 dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 114978 10197)
  (symbols 48 22012 1)
  (miscs 40 116 126)
  (strings 32 34678 2181)
  (string-bytes 1 892076)
  (vectors 16 17344)
  (vector-slots 8 521397 14092)
  (floats 8 68 61)
  (intervals 56 338 0)
  (buffers 992 17))

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Phil Sainty]

In fact that recipe was more complex than required.

I'd used text-mode because I'd noted that it had tooltips for its
menu -- but so does lisp-interaction-mode, I now realise.  So from
emacs -Q we can go directly to the major mode menu in the mode line,
without changing the major modes at all.  The same issue still occurs.

Likewise, the line-number-mode menu and the "All" to the left of
that both exhibit the same behaviours.


-Phil


On 2019-03-12 12:45, Phil Sainty wrote:
> Recipe from emacs -Q (and --with-x-toolkit=lucid)
> 
> * M-x text-mode
> * Mouse 1 click on "Text" in the mode line to open the menu
> * Hover over any of the menu items until the tooltip appears
> 
> For me, this produces tooltips of the appropriate dimensions, but the
> text itself is not visible.
> 
> When I use the top menu bar instead of the mode line, the tooltip text
> is visible.
> 
> I note also that if I simply hover over "Text" in the mode line, the
> "Major mode" tooltip appears with visible text; however if I click-and-
> hold the mouse button *before* the tooltip has had time to appear, then
> it will be blank when it does appear (over the top of the menu).
> 
> 
> -Phil

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Eli Zaretskii]

> Date: Tue, 12 Mar 2019 12:45:58 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> 
> Recipe from emacs -Q (and --with-x-toolkit=lucid)
> 
> * M-x text-mode
> * Mouse 1 click on "Text" in the mode line to open the menu
> * Hover over any of the menu items until the tooltip appears
> 
> For me, this produces tooltips of the appropriate dimensions, but the
> text itself is not visible.

I can only suggest to step with a debugger through x-show-tip and see
what's going on there.  It's hard to understand how come the frame is
shown, but the text produced by the same function is invisible.  Maybe
we are missing some X wizardry in that function.

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Eli Zaretskii]

> Date: Tue, 12 Mar 2019 19:28:53 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> 
> In fact that recipe was more complex than required.
> 
> I'd used text-mode because I'd noted that it had tooltips for its
> menu -- but so does lisp-interaction-mode, I now realise.  So from
> emacs -Q we can go directly to the major mode menu in the mode line,
> without changing the major modes at all.  The same issue still occurs.

What happens if you click C-mouse-3?  Does the menu that pops up have
valid help-echo or doesn't it?

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Eli Zaretskii]

> Date: Tue, 12 Mar 2019 17:56:56 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 34819@debbugs.gnu.org
> 
> What happens if you click C-mouse-3?

To clarify: I meant click C-mouse-3 on the text area of a window that
displays *scratch*.  It should pop up the menu of Lisp interaction
mode.

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Phil Sainty]

On 2019-03-13 06:21, Eli Zaretskii wrote:
>> What happens if you click C-mouse-3?
> 
> To clarify: I meant click C-mouse-3 on the text area of a window that
> displays *scratch*.  It should pop up the menu of Lisp interaction
> mode.

Blank tooltips again when the menu is accessed this way.


-Phil

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Glenn Morris]

Bisected to c29071587c64efb30792bd72248d3c791abd9337.

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 12 Mar 2019 17:06:10 -0400
> Cc: 34819@debbugs.gnu.org
> 
> Bisected to c29071587c64efb30792bd72248d3c791abd9337.

So the problem can be solved by adding (inhibit-double-buffering . t)
to tooltip-frame-parameters?  If so, I think we want this on the
release branch.

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Phil Sainty]

On 2019-03-13 16:34, Eli Zaretskii wrote:
>> Bisected to c29071587c64efb30792bd72248d3c791abd9337.
> 
> So the problem can be solved by adding (inhibit-double-buffering . t)
> to tooltip-frame-parameters?

Sadly not.  Starting a new emacs instance with the following did not
not have any apparent effect on the issue.

(custom-set-variables
  '(tooltip-frame-parameters
    (quote
     ((name . "tooltip")
      (internal-border-width . 2)
      (border-width . 1)
      (no-special-glyphs . t)
      (inhibit-double-buffering . t)))))

I also tried (set-frame-parameter nil 'inhibit-double-buffering t)
in the main frame, just in case that had an effect, but it did not.


-Phil

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Phil Sainty]

On 2019-03-13 10:06, Glenn Morris wrote:
> Bisected to c29071587c64efb30792bd72248d3c791abd9337.

I can confirm that for the current master, if I comment out parts
of configure.ac as below before building, the problem goes away.


### Use Xdbe (-lXdbe) if available
HAVE_XDBE=no
### if test "${HAVE_X11}" = "yes"; then
###   AC_CHECK_HEADER(X11/extensions/Xdbe.h,
###     [AC_CHECK_LIB(Xext, XdbeAllocateBackBufferName, HAVE_XDBE=yes)],
###     [],
###     [#include <X11/Xlib.h>
###     ])
###   if test $HAVE_XDBE = yes; then
###     XDBE_LIBS=-lXext
###   fi
###   if test $HAVE_XDBE = yes; then
###     AC_DEFINE(HAVE_XDBE, 1, [Define to 1 if you have the Xdbe 
extension.])
###   fi
### fi
AC_SUBST(XDBE_CFLAGS)
AC_SUBST(XDBE_LIBS)

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Eli Zaretskii]

On March 13, 2019 8:37:19 AM GMT+02:00, Phil Sainty <psainty@orcon.net.nz> wrote:
> On 2019-03-13 10:06, Glenn Morris wrote:
> > Bisected to c29071587c64efb30792bd72248d3c791abd9337.
> 
> I can confirm that for the current master, if I comment out parts
> of configure.ac as below before building, the problem goes away.
> 
> 
> ### Use Xdbe (-lXdbe) if available
> HAVE_XDBE=no
> ### if test "${HAVE_X11}" = "yes"; then
> ###   AC_CHECK_HEADER(X11/extensions/Xdbe.h,
> ###     [AC_CHECK_LIB(Xext, XdbeAllocateBackBufferName,
> HAVE_XDBE=yes)],
> ###     [],
> ###     [#include <X11/Xlib.h>
> ###     ])
> ###   if test $HAVE_XDBE = yes; then
> ###     XDBE_LIBS=-lXext
> ###   fi
> ###   if test $HAVE_XDBE = yes; then
> ###     AC_DEFINE(HAVE_XDBE, 1, [Define to 1 if you have the Xdbe 
> extension.])
> ###   fi
> ### fi
> AC_SUBST(XDBE_CFLAGS)
> AC_SUBST(XDBE_LIBS)

Which probably means the root cause is not double buffering itself, but some other change included in that commit.  I wonder if you can audit the changes and try to identify potential culprits.

Thanks.

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Phil Sainty]

On 13/03/19 11:31 PM, Eli Zaretskii wrote:
> On March 13, 2019 8:37:19 AM GMT+02:00, Phil Sainty <psainty@orcon.net.nz> wrote:
>> On 2019-03-13 10:06, Glenn Morris wrote:
>>> Bisected to c29071587c64efb30792bd72248d3c791abd9337.
>>
>> I can confirm that for the current master, if I comment out parts
>> of configure.ac as below before building, the problem goes away.
>>
>> ### Use Xdbe (-lXdbe) if available
>> HAVE_XDBE=no
>> ### if test "${HAVE_X11}" = "yes"; then
>> ###   AC_CHECK_HEADER(X11/extensions/Xdbe.h,
>> ###     [AC_CHECK_LIB(Xext, XdbeAllocateBackBufferName, HAVE_XDBE=yes)],
>> ###     [],
>> ###     [#include <X11/Xlib.h>
>> ###     ])
>> ###   if test $HAVE_XDBE = yes; then
>> ###     XDBE_LIBS=-lXext
>> ###   fi
>> ###   if test $HAVE_XDBE = yes; then
>> ###     AC_DEFINE(HAVE_XDBE, 1, [Define to 1 if you have the Xdbe extension.])
>> ###   fi
>> ### fi
>> AC_SUBST(XDBE_CFLAGS)
>> AC_SUBST(XDBE_LIBS)
> 
> Which probably means the root cause is not double buffering itself,
> but some other change included in that commit.  I wonder if you can
> audit the changes and try to identify potential culprits.

That code is well outside of my areas of expertise, so I'm not confident
that I'd figure it out very easily.

I'm CCing this to Daniel Colascione -- I don't imagine anyone else is
more familiar with that code than he is, so if anyone can intuitively
narrow down the possible culprits here, it would likely be him.

(Daniel, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34819 for full
context.)


-Phil

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Eli Zaretskii]

> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: Daniel Colascione <dancol@dancol.org>
> Date: Thu, 14 Mar 2019 00:52:43 +1300
> 
> > Which probably means the root cause is not double buffering itself,
> > but some other change included in that commit.  I wonder if you can
> > audit the changes and try to identify potential culprits.
> 
> That code is well outside of my areas of expertise, so I'm not confident
> that I'd figure it out very easily.
> 
> I'm CCing this to Daniel Colascione -- I don't imagine anyone else is
> more familiar with that code than he is, so if anyone can intuitively
> narrow down the possible culprits here, it would likely be him.

Btw, I reckon this doesn't happen in the GTK build?  What if you set
x-gtk-use-system-tooltips to a nil value -- does the problem happen in
the GTK build as well then?

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[dancol]

[-- Attachment #1: Type: text/html, Size: 1601 bytes --]

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Glenn Morris]

Eli Zaretskii wrote:

> What if you set x-gtk-use-system-tooltips to a nil value -- does the
> problem happen in the GTK build as well then?

Yes.

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Phil Sainty <psainty@orcon.net.nz>,  34819@debbugs.gnu.org,  dancol@dancol.org
> Date: Thu, 14 Mar 2019 01:57:03 -0400
> 
> Eli Zaretskii wrote:
> 
> > What if you set x-gtk-use-system-tooltips to a nil value -- does the
> > problem happen in the GTK build as well then?
> 
> Yes.

Thanks, then this seems to be a general problem with tooltips produced
by Emacs on X.

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Eli Zaretskii]

> Date: Wed, 13 Mar 2019 08:34:11 -0700
> From: dancol@dancol.org
> Cc: Phil Sainty <psainty@orcon.net.nz>, 34819@debbugs.gnu.org, rgm@gnu.org

Ping!  Any news on this?

> On Mar 13, 2019 8:25 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  > From: Phil Sainty <psainty@orcon.net.nz> 
>  > Cc: Daniel Colascione <dancol@dancol.org> 
>  > Date: Thu, 14 Mar 2019 00:52:43 +1300 
>  > 
>  > > Which probably means the root cause is not double buffering itself, 
>  > > but some other change included in that commit.  I wonder if you can 
>  > > audit the changes and try to identify potential culprits. 
>  > 
>  > That code is well outside of my areas of expertise, so I'm not confident 
>  > that I'd figure it out very easily. 
>  > 
>  > I'm CCing this to Daniel Colascione -- I don't imagine anyone else is 
>  > more familiar with that code than he is, so if anyone can intuitively 
>  > narrow down the possible culprits here, it would likely be him. 
> 
>  Btw, I reckon this doesn't happen in the GTK build?  What if you set 
>  x-gtk-use-system-tooltips to a nil value -- does the problem happen in 
> 
> Thanks. I'll take a look.
> 
>  the GTK build as well then? 

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Noam Postavsky]

merge 34819 33068
quit

Glenn Morris <rgm@gnu.org> writes:

> Eli Zaretskii wrote:
>
>> What if you set x-gtk-use-system-tooltips to a nil value -- does the
>> problem happen in the GTK build as well then?
>
> Yes.

That makes it the same as #33068 then, if I understand correctly.

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[martin rudalics]

> That makes it the same as #33068 then, if I understand correctly.

Good catch.  Do you have any ideas how to fix this?

martin

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Noam Postavsky]

martin rudalics <rudalics@gmx.at> writes:

>> That makes it the same as #33068 then, if I understand correctly.
>
> Good catch.  Do you have any ideas how to fix this?

No clue, sorry.

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[YAMAMOTO Mitsuharu]

The contents of the tooltip seems to be usually shown by the
flush_dirty_back_buffers call from handle_one_xevent.  But the control
does not go back to read_socket_hook during menu tracking, so
flush_dirty_back_buffers is not called in such a case.

The patch below would work.  The first hunk is not directly related to
this bug, but would be preferable.  Note that cairo drawing needs
further fixes, so please try it without enabling cairo.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

diff --git a/src/xfns.c b/src/xfns.c
index c9fe3e11f2d..fb30a2f440a 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -6288,6 +6288,10 @@ x_create_tip_frame (struct x_display_info *dpyinfo, Lisp_Object parms)
 
   f->output_data.x->parent_desc = FRAME_DISPLAY_INFO (f)->root_window;
 
+  gui_default_parameter (f, parms, Qinhibit_double_buffering, Qnil,
+                         "inhibitDoubleBuffering", "InhibitDoubleBuffering",
+                         RES_TYPE_BOOLEAN);
+
   gui_figure_window_size (f, parms, false, &x_width, &x_height);
 
   {
@@ -6958,6 +6962,7 @@ Text larger than the specified size is clipped.  */)
 
   w->must_be_updated_p = true;
   update_single_window (w);
+  flush_frame (tip_f);
   set_buffer_internal_1 (old_buffer);
   unbind_to (count_1, Qnil);
   windows_or_buffers_changed = old_windows_or_buffers_changed;

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[YAMAMOTO Mitsuharu]

On Thu, 20 Jun 2019 14:01:54 +0900,
YAMAMOTO Mitsuharu wrote:
> 
> The contents of the tooltip seems to be usually shown by the
> flush_dirty_back_buffers call from handle_one_xevent.  But the control
> does not go back to read_socket_hook during menu tracking, so
> flush_dirty_back_buffers is not called in such a case.

The argument was too rough, actually.  During menu tracking,
handle_one_xevent is called via popup_get_selection and
x_dispatch_event.  Difference should come from other places.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[mituharu]

> On Thu, 20 Jun 2019 14:01:54 +0900,
> YAMAMOTO Mitsuharu wrote:
>>
>> The contents of the tooltip seems to be usually shown by the
>> flush_dirty_back_buffers call from handle_one_xevent.  But the control
>> does not go back to read_socket_hook during menu tracking, so
>> flush_dirty_back_buffers is not called in such a case.
>
> The argument was too rough, actually.  During menu tracking,
> handle_one_xevent is called via popup_get_selection and
> x_dispatch_event.  Difference should come from other places.

It turns out the contents of the tooltip is usually shown by
unblock_buffer_flips in double-buffer setting.  Calls to
flush_dirty_back_buffers do not contribute to tooltip display
because FRAME_GARBAGED_P is set for the tooltip frame.

I think the patch I posted previously does the right thing.
Please try it.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[Phil Sainty]

On 20/06/19 11:04 PM, mituharu@math.s.chiba-u.ac.jp wrote:
> I think the patch I posted previously does the right thing.
> Please try it.

Thanks; I've just built and tested with this patch, and it does
indeed seem to resolve the problem.

I'm not able to review the code change, but all my previous test
cases are now displaying their tooltips correctly.


-Phil

bug#34819: 26.1; Blank help-echo tooltips for mode line menus

[YAMAMOTO Mitsuharu]

On Wed, 26 Jun 2019 21:56:13 +0900,
Phil Sainty wrote:
> 
> On 20/06/19 11:04 PM, mituharu@math.s.chiba-u.ac.jp wrote:
> > I think the patch I posted previously does the right thing.
> > Please try it.
> 
> Thanks; I've just built and tested with this patch, and it does
> indeed seem to resolve the problem.
> 
> I'm not able to review the code change, but all my previous test
> cases are now displaying their tooltips correctly.

Thanks for testing.  I've pushed the patch to master as 82d6b390b5e
(flush_frame part) and 4a5a74a07ff (inhibit-double-buffering part).
Closing the bug.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp