Bug 123972 - UI menu disappears before submenu can open (GTK3 and Wayland)
Summary: UI menu disappears before submenu can open (GTK3 and Wayland)
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.3.3.2 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Main-Menu Wayland a11y GTK3
  Show dependency treegraph
 
Reported: 2019-03-09 21:20 UTC by Nick Levinson
Modified: 2021-05-01 10:21 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
The upper part shows the menu that I have. I wonder if the lower part is what Nick has (107.58 KB, image/png)
2020-04-29 16:29 UTC, Bart
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Levinson 2019-03-09 21:20:19 UTC
Description:
In LO version 6.1.5.2, using an alt-character shortcut to open a menu that has a submenu for the first menu item and releasing the keys before the submenu opens causes the menu to close. You have to open it again and hold it (albeit not for long) till the submenu opens, then you can proceed normally.

In Writer and Calc, this is with the File and Format menus. In LibreOffice with no document open, this is with the File menu.

Keeping the keys down until the submenu opens results in correct behavior. If the first menu item does not have a submenu, the menu behavior is correct.

I did not test the other major subprograms (on my installation, Draw, Math, and Base).

To a speed typist, this can make LibreOffice look broken.

Steps to Reproduce:
Per description.

Actual Results:
Menu disappears.

Expected Results:
Menu should stay to allow selection of item or submenu.


Reproducible: Always


User Profile Reset: No



Additional Info:
Not sure how long this has been happening; may not be for this version only.
Comment 1 Dieter 2019-03-10 16:37:27 UTC
I can't reproduce it with

Version: 6.1.5.2 (x64)
Build-ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group threaded

Perhaps only Linux?
Comment 2 Xisco Faulí 2019-03-14 18:50:57 UTC
Thank you for reporting the bug. To be certain the reported issue is not
related to corruption in the user profile, could you please reset your
Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and
re-test?

I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the issue is still present
Comment 3 Nick Levinson 2019-03-16 18:53:28 UTC
I "[r]eset entire user profile" from Safe Mode. The problem is the same.
Comment 4 Xisco Faulí 2019-03-18 20:03:34 UTC
Could you please paste the info from Help - about LibreOffice ?

I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' once the information has been provided
Comment 5 Nick Levinson 2019-03-20 01:45:33 UTC
From Help > About LibreOffice:

Version: 6.1.5.2

Build ID: 6.1.5.2-2.fc29

CPU threads: 2; OS: Linux 4.20; UI render: default; VCL: gtk3; 

Locale: en-US (en_US.UTF-8); Calc: group threaded
Comment 6 Peter Vágner 2019-03-20 13:20:32 UTC
I am using Libreoffice on a Gnome desktop running Arch linux.
Pressing alt key alone does not open the menu and it's expected.
I am unable to reproduce this for example by pressing alt+f for the file menu or F10.
 I am not sure I'm good candidate for testing this though.

Version: 6.2.1.2
Build ID: 6.2.1-1
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: en-US (en); UI-Language: en-US
Calc: threaded
Comment 7 Xisco Faulí 2019-07-08 16:00:06 UTC
A new major release of LibreOffice is available since this bug was reported.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 8 Nick Levinson 2019-07-13 18:32:23 UTC
The problem remains.

Since LO's website offers 6.2, I assume that's a major version, and I have 6.2.4.2.0+ (Build ID 6.2.4.2-4.fc30; CPU threads 2; OS Linux 5.1; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US; Calc: threaded).

Alt alone causes underlining but doesn't open a menu and, I think, shouldn't (LO wouldn't know from alt alone which menu to open, thus I disagree with comment 6).

But alt-f opens the file menu. If I let it go too quickly, the menu closes. I have to keep it open long enough that the first submenu opens. Then I can let the keyboard go because the menu and the submenu will stay open for my next decision. I limited my testing this time to Writer and the File and Format (alt-o) menus, but the problem probably remains for Calc and for having nothing open. By releasing quickly, I was able to reproduce the problem ten times consecutively with alt-o.
Comment 9 Xisco Faulí 2020-01-20 17:06:42 UTC
Hello Nick,
A new major release of LibreOffice is available since this bug was reported.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 10 Nick Levinson 2020-01-25 21:12:00 UTC
That page offers LO 6.3.4 for early adopters and I don't want to introduce instability onto my laptop and for stability it offers LO 6.2.8 when I already have 6.3.3.2.

The effect continues, with Writer alt-f (File menu) or alt-o (Format menu). If released too quickly for the first menu item's submenu to open, the menu closes. The menu has to be reselected to open the submenu.
Comment 11 Xisco Faulí 2020-01-28 11:31:55 UTC
Hello Nick,
Does it work for you if you launch LibreOffice from commandline with
'SAL_USE_VCLPLUGIN=gen soffice' ?
Comment 12 Nick Levinson 2020-02-01 17:59:55 UTC
I don't know how to do that and instructions I found on the Web were either unclear or 5+ years old, such as which directory to go to (LO may have changed since then and I might cause myself a problem if I apply outdated instructions).

Also, I don't run LO from the CLI. I use the GUI and need LO to work that way.

I don't have any plugins except whatever came with the default installation with my distro (Fedora 31 Linux), and I doubt any came with that installation.
Comment 13 Bart 2020-04-29 16:27:31 UTC
I'm trying to reproduce Nick's situation. I do hope that I understand his problem correctly.

I also have LibreOffice 6.1.5.2 and I'm using Linux/Debian 10 with the LXDE interface. (I can easily switch to other interfaces.) 

In my case the main menu is visible all the time. If I can hide it, I should be closer to the situation that Nick has and then try to reproduce it. I tried to find a setting to hide the main menu, but I couldn't find it. 

Would anyone here know how to hide the menu? Maybe then I can be of more help.

I added a screen copy of what I have, and what I think Nick has.

Nick, is F10 an option for you? In my case it opens the "File" submenu. When you hit the "right" key you can then open the "Edit" , "View" , "Insert" submenu, etc.

PS:
I'm not a developer. I submitted a few bugs/requests myself and I'm trying to confirm other bugs/requests.
Comment 14 Bart 2020-04-29 16:29:51 UTC
Created attachment 160085 [details]
The upper part shows the menu that I have. I wonder if the lower part is what Nick has

The upper part of this image shows the menu that I usually have. 

The lower part of this image is photoshopped. I wonder if this is what Nick has
Comment 15 Nick Levinson 2020-05-22 21:09:29 UTC
I didn't answer earlier, due to Covid-19 restrictions.

Comment 13:

Your menubar may be open all the time. I doubt the File menu is open all the time on anyone's setup. To have the File menu open all the time would mean you're ready to select a menu command (menu item) such as Open or Close but without ever selecting any command in that menu, and in that case I doubt you'd ever get any work done.

The menu is not hidden when you don't see it, it's closed. If you select a  menu command, the menu then closes while it carries out your command. So, if you select the Print command, the menu closes and the Print dialog opens. You might hide the menubar (and I don't know how to do that except perhaps by using Tools > Customize > Menus and deleting every command from every menu, if you have any reason to do that), but I'm not talking about the menubar. I'm interested only in each menu (and its submenus).

In other words: One menu is called File. Another menu is called Edit. They're in the same menubar, but, in that menubar, File and Edit are separate menus.

To see a submenu, open the File menu (alt-f) and select New. Then another menu will open, offering Text Document, Spreadsheet, and so on. That's a submenu.

F10 opens the File menu. As far as I know, it's just like clicking "File" or typing alt-f. F10 is not the issue in this bug report.

Comment 14: Your attachment's top shows a menubar, not a menu. I'm talking about a menu, such as the File menu. You see the menu when you open it, such as by mouse-clicking "File" or typing alt-f.
Comment 16 Buovjaga 2020-08-31 17:11:16 UTC
(In reply to Nick Levinson from comment #12)
> I don't know how to do that and instructions I found on the Web were either
> unclear or 5+ years old, such as which directory to go to (LO may have
> changed since then and I might cause myself a problem if I apply outdated
> instructions).
> 
> Also, I don't run LO from the CLI. I use the GUI and need LO to work that
> way.

This is simply for testing, we are not advocating for you to start launching from the command line.

You can test any version without it affecting your existing installation by using an appimage: https://libreoffice.soluzioniopen.com/

To test Xisco's suggestion with any appimage:
1. open your terminal
2. cd into the directory where the appimage is
3. Make it executable: chmod +x nameofappimage
4. SAL_USE_VCLPLUGIN=gen ./nameofappimage
Comment 17 Nick Levinson 2020-09-20 22:26:25 UTC
I opted for version 7.0.1 (Fresh), because it's the latest classified as stable. I opted for Fresh Portable, specifically LibreOffice-7.0.1.en-GB.help-x86_64.AppImage . Saving did not let me choose the destination directory or to open it without saving. It was saved by default to the Downloads directory but double-clicking it failed to identify an app that would open it. I went to /usr but, acting as nonroot, couldn't create a new directory (to prevent confusion with anything else that might get written into /usr). Since I shouldn't need root access for the purpose and running as root is a security risk, I chose to copy the file into /Home/Desktop (I guess that's in my account directory). Using Properties, I set it to executable. I double-clicked it and it opened, showing me the LO desktop, which had a new design compared to the LO version I usually use. The new one is still called soffice, which I guess dates from StarOffice days. So I went back, per your instructions, to the CLI and ran SAL_USE_VCLPLUGIN=gen .

I've now run the new LO from the AppImage two ways:

Without SAL_USE_VCLPLUGIN=gen , the problem remains. I should emphasize a point that may explain why people above could not reproduce the problem. With alt-f or alt-o, even if you release the letter quickly, the menu behaves correctly unless you also release alt quickly after the letter, and speed typists are likely to release both quickly. Quick release of both (in the right order) causes the menu to open and close too quickly for use. You can't select a command.

(Quickly releasing in the wrong order is a trivial case. The menu might not open at all, and that's as expected.)

But with SAL_USE_VCLPLUGIN=gen , the problem is absent. The menus look different and they behave correctly even with quick release of both keys.

Conclusion so far: without the environment variable and value (SAL_USE_VCLPLUGIN=gen), quickly releasing both keys causes the misbehavior. With the variable and value, the behavior is right.
Comment 18 Buovjaga 2020-09-21 04:25:20 UTC
(In reply to Nick Levinson from comment #17)
> Conclusion so far: without the environment variable and value
> (SAL_USE_VCLPLUGIN=gen), quickly releasing both keys causes the misbehavior.
> With the variable and value, the behavior is right.

Ok, that is interesting. You could also test with SAL_USE_VCLPLUGIN=kf5 to get another data point. Then we can at least tweak the summary.
Comment 19 Nick Levinson 2020-09-28 23:42:28 UTC
I tested with the new value, using version 7.0.1 (Fresh) (the latest that's described as stable), portable, specifically LibreOffice-7.0.1.en-GB.help-x86_64.AppImage . I copied it and set the copy via GUI Properties to executable. I ran the copy via Terminal with SAL_USE_VCLPLUGIN=kf5 .

The AppImage includes Impress; I don't have Impress in my old (non-AppImage) installation, but I don't think that should make a difference in menu/submenu behavior.

Before these tests, I exited my old LO, to prevent confusion. I know the .AppImage LO versions were being tested because I saw the artwork on the empty LO desktops (my old LO has different artwork there).

In the AppImage's Writer, the File and Format menus each displayed the menu in two positions, alternating between dropping down from the menu title and mounting with the menu's top above the menu title's baseline, possibly at the top of the window. The alternation stops if a submenu command is applied, so that the alternation sequence starts again from dropping down from the menu title. Alternation happens even if the menu is contained completelly within the viewport; this can be seen with the empty LO desktop and its File menu. In one series of attempts to open Writer's Format menu, it always dropped down from the menu title; I don't know why the exception that time.

With either position, the menu and a submenu behaved correctly.

This is the .AppImage's Help > About LO dialog's information via its button for copying: "Version: 7.0.1.2"/"Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452"/"CPU threads: 2; OS: Linux 5.8; UI render: default; VCL: gtk3"/"Locale: en-US (en_US.UTF-8); UI: en-US"/"Calc: threaded".

This might be of interest: When, with an unsaved Writer document with one character open, I opened the File menu and the New submenu and selected the Templates... command (suspension points so in original), displaying the Templates dialog, in which I did nothing. This created the following in the CLI terminal:

qt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x3684420) which does not match the current topmost grabbing popup, QtWaylandClient::QWaylandXdgSurface(0x809d180) According to the xdg-shell protocol, this is not allowed. The wayland QPA plugin is currently handling it by setting the parent to the topmost grabbing popup. Note, however, that this may cause positioning errors and popups closing unxpectedly because xdg-shell mandate that child popups close before parents
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

New conclusion, so far, not counting the CLI output: 7.0.1 Fresh behaved correctly with gen and with kf5 while my old LO ("Version: 6.4.6.2"/"Build ID: 6.4.6.2-2.fc32"/"CPU threads: 2; OS: Linux 5.8; UI render: default; VCL: gtk3; "/"Locale: en-US (en_US.UTF-8); UI-Language: en-US"/"Calc: threaded") still misbehaved in Writer as described above.
Comment 20 Buovjaga 2020-09-29 07:37:43 UTC
(In reply to Nick Levinson from comment #19)
> qt.qpa.wayland: setGrabPopup called with a parent,
> QtWaylandClient::QWaylandXdgSurface(0x3684420) which does not match the
> current topmost grabbing popup,
> QtWaylandClient::QWaylandXdgSurface(0x809d180) According to the xdg-shell
> protocol, this is not allowed. The wayland QPA plugin is currently handling
> it by setting the parent to the topmost grabbing popup. Note, however, that
> this may cause positioning errors and popups closing unxpectedly because
> xdg-shell mandate that child popups close before parents
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

Ooh, you are running a Wayland session. In this case, it would be important to log out and log into an X11 session to test, if it works correctly with GTK3.
Comment 21 Caolán McNamara 2020-09-29 08:18:15 UTC
I can't reproduce any such problem on wayland + gtk + fedora 32, but it would be interesting to compare against another gtk3-using application with a menubar to see if there is a difference. e.g. gtk3-demo and double click "Application Class" to try its menubar demo, and see if the problem is a generic one or a specific LibreOffice one
Comment 22 Nick Levinson 2020-11-04 02:38:15 UTC
In response to comment 20:

I changed from Wayland to X11, but logging out doesn't do it; a warm reboot is necessary.

I now run Fedora 33, kept evergreen.

I tested Writer's File and Format menus.

The problem does not occur under X11. I think my fingering was fast enough for the test to be reasonable. I switched back to Wayland and the problem resumed.

From the Help > About LibreOffice dialog:

Version: 7.0.2.2
Environment: CPU threads: 2; OS: Linux 5.8
User Interface: UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Misc: Calc: threaded
Comment 23 Buovjaga 2021-05-01 10:21:06 UTC
I get console spam for
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

when fooling around with menus in a Wayland session and kf5 VCL backend. It coincides with LibreOffice crashing.

Under gdb I can't make it crash, but I get these:

qt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x555556eb2a50) which does not match the current topmost grabbing popup, QtWaylandClient::QWaylandXdgSurface(0x55555a5e8200) According to the xdg-shell protocol, this is not allowed. The wayland QPA plugin is currently handling it by setting the parent to the topmost grabbing popup. Note, however, that this may cause positioning errors and popups closing unxpectedly because xdg-shell mandate that child popups close before parents

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: fe2f5f99636d938d57c1880c37d54c1b796f06f1
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded