Bug 132028 - LO 6.3.x/6.4.x No Menu and Very Slow Keyboard with GTK3 VCL
Summary: LO 6.3.x/6.4.x No Menu and Very Slow Keyboard with GTK3 VCL
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.3.5.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-10 16:07 UTC by FR
Modified: 2020-07-23 16:17 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
LO with SAL_USE_VCLPLUGIN=gtk3 (15.93 KB, image/png)
2020-04-10 16:07 UTC, FR
Details
LO with SAL_USE_VCLPLUGIN=gen (16.84 KB, image/png)
2020-04-10 16:08 UTC, FR
Details

Note You need to log in before you can comment on or make changes to this bug.
Description FR 2020-04-10 16:07:19 UTC
Created attachment 159470 [details]
LO with SAL_USE_VCLPLUGIN=gtk3

LO 6.3.x/6.4.x has become non-functional for me because the menu bar is no longer visible and the keyboard input is extremely slow.

I have determined that this problem is duw to the GTK3 VCL.

If I set the variable SAL_USE_VCLPLUGIN=gtk3 the result is no menu bar and extremely slow reponsiveness.

If I set the variable SAL_USE_VCLPLUGIN=gen, the generic X11 interface, the result is a visible menu bar and normal behavior.

I can use LO with the generic X11 interface but the menu and dialog fonts are very small with no way to increase the font size.  I would rather use the GTK3 interface.

My system is Gentoo Linux.  I have no desktop environment and use only the FVWM window manager.

LO has always functioned well on this system until the use of the VCL with GTK3 starting in LO 6.2 or LO 6.3.

I have attached PNG images showing the absence of the menu bar (SAL_USE_VCLPLUGIN=gtk3) and with the menu bar (SAL_USE_VCLPLUGIN=gen).

Is there any way that I can debug this further?
Comment 1 FR 2020-04-10 16:08:24 UTC
Created attachment 159471 [details]
LO with SAL_USE_VCLPLUGIN=gen
Comment 2 Julien Nabet 2020-04-11 15:40:49 UTC
You can give a try at https://wiki.documentfoundation.org/QA/FirstSteps

Could you give a try to 6.4.2 version?
Indeed, except master branch (future release 7.0), most of fixes are now on 6.4 branch.
Comment 3 FR 2020-04-11 16:07:21 UTC
(In reply to Julien Nabet from comment #2)
> 
> Could you give a try to 6.4.2 version?
> 

I am using version 6.4.2.2:

Help --> About LibreOffice

Version: 6.4.2.2
Build ID: Gentoo official package
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: x11; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded


Although this build is Gentoo, the same problem happens
with the binary distribtion package from libreoffice.org.

For me, the problem began with 6.3.x and is still present
with 6.4.x.

I can wait until 7.0 is released and maybe it will be
fixed.
Comment 4 Julien Nabet 2020-04-11 16:27:01 UTC
Could you try this:
https://wiki.documentfoundation.org/QA/FirstSteps

It allows to see if it can be a corrupted profile or OpenGL pb.
Comment 5 FR 2020-04-11 17:23:19 UTC
(In reply to Julien Nabet from comment #4)
> Could you try this:
> https://wiki.documentfoundation.org/QA/FirstSteps
> 
> It allows to see if it can be a corrupted profile or OpenGL pb.
>

OpenGL is disabled.  Old profile is deleted.

The same problem occurs.  No menu.  Very slow input response.

Here are error messages that occur when LO is started with SAL_USE_VCLPLUGIN=gtk3:


** (soffice:15113): CRITICAL **: 13:15:15.387: void g_lo_menu_insert_section(GLOMenu*, gint, const gchar*, GMenuModel*): assertion 'G_IS_LO_MENU (menu)' failed

(soffice:15113): Gtk-CRITICAL **: 13:15:15.387: gtk_menu_bar_new_from_model: assertion 'G_IS_MENU_MODEL (model)' failed

(soffice:15113): Gtk-CRITICAL **: 13:15:15.387: gtk_widget_insert_action_group: assertion 'GTK_IS_WIDGET (widget)' failed

(soffice:15113): Gtk-CRITICAL **: 13:15:15.387: gtk_widget_set_hexpand: assertion 'GTK_IS_WIDGET (widget)' failed

(soffice:15113): Gtk-CRITICAL **: 13:15:15.387: gtk_container_add: assertion 'GTK_IS_WIDGET (widget)' failed

(soffice:15113): GLib-GObject-WARNING **: 13:15:15.387: invalid (NULL) pointer instance

(soffice:15113): GLib-GObject-CRITICAL **: 13:15:15.387: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(soffice:15113): GLib-GObject-WARNING **: 13:15:15.387: invalid (NULL) pointer instance

(soffice:15113): GLib-GObject-CRITICAL **: 13:15:15.387: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(soffice:15113): Gtk-CRITICAL **: 13:15:15.387: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed

(soffice:15113): Gtk-CRITICAL **: 13:15:15.394: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed

(soffice:15113): Gtk-CRITICAL **: 13:15:15.397: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed

(soffice:15113): Gtk-CRITICAL **: 13:15:15.400: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed

(soffice:15113): Gtk-CRITICAL **: 13:15:15.403: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed

(soffice:15113): Gtk-CRITICAL **: 13:15:15.419: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed



These error messages DO NOT occur with SAL_USE_VCLPLUGIN=gen.
Comment 6 Julien Nabet 2020-04-11 17:56:32 UTC
(In reply to FR from comment #5)
> ...
> These error messages DO NOT occur with SAL_USE_VCLPLUGIN=gen.

Quite expected since you don't use gtk3 with gen rendering.

Caolán: thought you might be interested in this one. I'm a bit stuck since I don't reproduce this + since the reporter uses Gentoo, I suppose gtk/gnome libs are quite recent.
Comment 7 Caolán McNamara 2020-04-11 18:22:01 UTC
"I can wait until 7.0 is released and maybe it will be fixed." I suspect that will almost certainly make no difference because as far as I know there hasn't been any changes to the menubar/menu stuff in 7.0

With a gentoo setup I guess its hard to reproduce the environment which causes this, maybe its some missing dbus related thing. Is there anything like a VirtualBox image in which the problem can be seen ?
Comment 8 FR 2020-04-11 18:49:44 UTC
(In reply to Caolán McNamara from comment #7)
> 
>  maybe its some missing dbus related thing.
>

Thanks for this hint.  I have a minimalist system with only the FVWM window manager and dbus is disabled.

But as I test, I started dbus and then started LO.  Now the menu bar is visible and functional.  Also, the errors messages that I pasted previously are gone.

However, keyboard input is still extremely sluggish.  For example, if I hold down a key in Writer the repeat rate is about 1 per second whereas normally it is several times a second.

So half the problem is solved.  With dbus running, the menu bar is back but the keyboard input is still extremely slow.
Comment 9 Caolán McNamara 2020-04-12 14:07:48 UTC
does the keyboard problem appear in e.g. gedit also ? or just libreoffice ?
Comment 10 FR 2020-04-12 15:07:57 UTC
(In reply to Caolán McNamara from comment #9)
> does the keyboard problem appear in e.g. gedit also ? or just libreoffice ?
>

I don't have gedit installed.  Gedit is part of the Gnome DE and I don't use any DE.  I just use X and the fvwm window manager.

But I did notice that the slow keyboard input seems to apply only to text areas of an application.

For example, on menu dialogs, such as "Save As...," keyboard input is normal.

Also, when using the arrow keys in Calc to move across cell ranges, the keyboard input is normal.  But when I input text into a cell or use the arrow keys within a cell then the keyboard input is very sluggish.

The arrow keys also function normally in dialogs such as "File Open" or "Save As..."

However, in Writer, the arrow keys become very sluggish because the cursor is being moved across regions of rendered text.

Based on this behavior, I would guess that the problem is one of font rendering or something related to font rendering.
Comment 11 FR 2020-04-12 15:57:24 UTC
(In reply to Caolán McNamara from comment #9)
> does the keyboard problem appear in e.g. gedit also ? or just libreoffice ?
>

I don't use gedit, but I do regularly use another two GTK+3 based text editors:

Geany -- https://geany.org/

Bluefish -- http://bluefish.openoffice.nl/index.html

The Bluefish GUI resmbles LO very close;y.

There are no problems with either of these editors.
Comment 12 Alex Thurgood 2020-04-16 07:21:14 UTC
FWIW, on a PC running Ubuntu 16.04 distrib, I experience the same thing when building from master with gtk3 enabled and the default desktop environment (Unity), or the Mate desktop environment.

If I switch to XFCE or Enlightenment, I get the menu back again.
Comment 13 Alex Thurgood 2020-04-16 07:22:59 UTC
(In reply to Alex Thurgood from comment #12)
> FWIW, on a PC running Ubuntu 16.04 distrib, I experience the same thing when
> building from master with gtk3 enabled and the default desktop environment
> (Unity), or the Mate desktop environment.
> 
> If I switch to XFCE or Enlightenment, I get the menu back again.

I would just add that this has been the case with my master builds on that machine for some considerable time now, at least 6 months, possibly even longer.
Comment 14 Julien Nabet 2020-04-16 09:00:38 UTC
Alex: I wonder if it could be due to the fact your libs may be a bit old.
Indeed Ubuntu 16.04 is the previous LTS. Meanwhile 18.04 has been released and there'll be soon 20.04

Would you be interested in trying Flamegraph to find bottleneck? (see http://www.brendangregg.com/flamegraphs.html)
You need a build with enable-symbols. I don't know if it's ok with enable-dbgutil but that's the reason I got 2 local builds in my machine.

I know I need to type this only once for a session if I want to use Flamegraph:
 sh -c 'echo 1 >/proc/sys/kernel/perf_event_paranoid'
(don't know if it's required for every machine)

then I use these 2 alias:
alias perflibo='perf record -F 200 --call-graph dwarf --pid=`pidof soffice.bin`'
alias perfsvg='perf script | /home/julien/projects/FlameGraph/stackcollapse-perf.pl | /home/julien/projects/FlameGraph/flamegraph.pl --width 4096 --height 24 > perf.svg'

(I just git clone Flamegraph in /home/julien/projects)

perflibo is to retrieve traces
perfsvg is to generate the graph.

See https://wiki.documentfoundation.org/Development/How_to_debug#Performance_debugging_.28perf.29
Comment 15 Am Jam 2020-05-28 00:22:09 UTC
Just confirming that my upgrade to libreoffice-6.4.3.2 generated this bug of the missing menu bar. With prior versions of libreoffice, I got around the bug by prefixing the libreoffice command with SAL_USE_VCLPLUGIN=gtk or SAL_USE_VCLPLUGIN=gen. However, with libreoffice-6.4.3.2, neither worked. I use Gentoo and don't use a DE; I just have dwm as my window manager. 

Re-emerging dbus with "USE=X" helped. For non-Gentoo folks, that means making sure dbus is compiled with added support for X11. I'm using dbus-1.12.16 as of this writing.
Comment 16 Timur 2020-06-16 06:21:45 UTC
Is this same as bug 134005? Ubuntu bug?
Comment 17 FR 2020-07-23 15:38:03 UTC
The issue is SOLVED.

The trouble is that GTK+3 VCLPLUGIN somehow requires DBUS to be running or else no menus will appear.  Starting or invoking DBUS before starting LibreOffice will solve the menu issue.

This may pose problems for people who operate a GNU/Linux system without a desktop environment like GNOME.  Not everyone uses a DE and they will certainly experience an absence of menus.

Regarding the sluggish keyboard, this issue was related to a certain MTRR configuration for Linux and has nothing to do with LibreOffice.

But the trend of LibreOffice to adopt more and more desktop dependencies will mean that users that choose not to use a DE will suffer problems in the future.
Comment 18 Julien Nabet 2020-07-23 16:17:19 UTC
Let's put this one to WFM instead since there's no specific fix.