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

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

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))




Reply | Threaded
Open this post in threaded view
|

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




Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Phil Sainty
> Date: Tue, 12 Mar 2019 12:45:58 +1300
> From: Phil Sainty <[hidden email]>
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Phil Sainty
> Date: Tue, 12 Mar 2019 19:28:53 +1300
> From: Phil Sainty <[hidden email]>
>
> 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?



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> Cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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




Reply | Threaded
Open this post in threaded view
|

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

Glenn Morris-3
In reply to this post by Phil Sainty

Bisected to c29071587c64efb30792bd72248d3c791abd9337.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Glenn Morris <[hidden email]>
> Date: Tue, 12 Mar 2019 17:06:10 -0400
> Cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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




Reply | Threaded
Open this post in threaded view
|

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

Phil Sainty
In reply to this post by Glenn Morris-3
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)





Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Phil Sainty <[hidden email]>
> Cc: Daniel Colascione <[hidden email]>
> 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?



Reply | Threaded
Open this post in threaded view
|

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

Daniel Colascione-5
On Mar 13, 2019 8:25 AM, Eli Zaretskii <[hidden email]> wrote:

> From: Phil Sainty <[hidden email]>
> Cc: Daniel Colascione <[hidden email]>
> 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?


Reply | Threaded
Open this post in threaded view
|

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

Glenn Morris-3
In reply to this post by Eli Zaretskii
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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Glenn Morris <[hidden email]>
> Cc: Phil Sainty <[hidden email]>,  [hidden email],  [hidden email]
> 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.