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.
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?
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
I "[r]eset entire user profile" from Safe Mode. The problem is the same.
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
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
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
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.
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.
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.
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.
Hello Nick, Does it work for you if you launch LibreOffice from commandline with 'SAL_USE_VCLPLUGIN=gen soffice' ?
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.
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.
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
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.
(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
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.
(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.
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.
(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.
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
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
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
no repro in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 7c38362dbe1922c9825dffb463072030948d406b CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-US (ru_RU); UI: en-US Calc: CL
Does this still happen for you in current LO versions? If so, can you please provide the exact version information from "Help" -> "About LibreOffice" and what Linux distro (+ version of it) you're using now?
With Orca 44.2 in Ubuntu 22.04 and LO 7.5.4 I do not have issues. Menu and sub menu behave as expected after pressing F10 tand arrow down in the several menu options. Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3 Ubuntu package version: 4:7.5.4~rc2-0ubuntu0.22.04.1~lo1
Dear Nick Levinson, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
The problem remains. This is about using menu alt-character shortcuts, not F10. Menu alt-character shortcuts are made available because speed typists expect them, but the reported problem still applies and thus defeats them. F10 and arrows work without this problem. But menu alt-character shortcuts (mainly in Word or Calc the File menu by alt-f or the Format menu by alt-o) should also work as expected. If you're a fast typist, you use the keys in the proper order (hold alt down, type the character, release the character, and release alt) and then go to your next step. But, in that case, when the menu opens, if the first menu command has a submenu, the menu closes before the submenu can open. So the typist has to repeat the step or use another tactic, either way being slowed. If the typist is looking at an original document and not at the screen, they may be unaware that the command didn't apply and subsequent typing may have unexpected results, which may have to be fixed, slowing the typist. Help menu > About LO: Version: 7.6.4.1 (X86_64) Build ID: 60(Build:1) CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Wayland is probably still running unless the default was changed. I don't want to try a newer LO version until included in a Fedora Linux distro update. I'm not set up to use appimages now.
For Bug 123972, which concerns the disappearance of the UI menu before the submenu can open on GTK3 and Wayland, the issue likely stems from a compatibility issue between GTK3 and the Wayland display server protocol. It seems that the menu system may be encountering a timing or rendering problem that causes it to vanish prematurely. To address this, developers may need to investigate and possibly modify the code related to menu rendering and interaction, ensuring proper synchronization between the UI elements and the Wayland display server. Additionally, testing across different environments and configurations could help pinpoint the root cause and facilitate the implementation of an effective solution. For further insights into photo editing apps that might offer alternative solutions or workarounds, you can explore our curated list of https://getreminiproapk.com/top-10-photo-editing-apps-for-ios-and-android//]