Created attachment 189411 [details] This File menu was in the middle of the screen I can't quite figure a pattern for this, but menus in Calc or Writer randomly are placed somewhere else on the screen, instead of dropping from the menu bar under their menu item. Moving the mouse over where the menu should be, results in the highlight moving in the menu, a process that feels like the cursor is being teleported/translated on both axes. Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 20; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Operating System: Fedora Linux 38 KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.109.0 Qt Version: 5.15.10 Kernel Version: 6.4.13-200.fc38.x86_64 (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i7-12700H Memory: 62.5 GiB of RAM Graphics Processor: Mesa Intel® Graphics
Reproducible. Version: 7.6.0.3 (X86_64) / LibreOffice Community Build ID: 60(Build:3) CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_US.UTF-8); UI: en-US 7.6.0-1 Calc: threaded KDE Plasma version: 5.27.7 KDE Frameworks version: 5.109.0 Qt Version: 5.15.10 Kernel Version: 6.1.49-1-MANJARO (64-bit) Graphics Platform: Wayland Steps to reproduce: 1. Open Writer. 2. Open another application. 3. Click on the window of another application and make sure focus is on the other application's window. 4. Right-click on the Writer window. Expected result: Right-click context menu shown inline Actual result: Right-click context menu shown with its own title bar, with soffice.bin as the title, on the top left of the screen.
I can't reproduce the issue with LO 24.2.5 on Fedora 40 (KDE Plasma 6.1). Version: 24.2.5.2 (X86_64) Build ID: 420(Build:2) CPU threads: 12; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: pt-BR (en_US.UTF-8); UI: en-US Calc: threaded Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.5-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × Intel® Core™ i7-10750H CPU @ 2.60GHz Memory: 15,5 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics Manufacturer: LENOVO Product Name: 82CG System Version: IdeaPad Gaming 3 15IMH05 Can you test it again?
Dear Dan Dascalescu, 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
*** Bug 165342 has been marked as a duplicate of this bug. ***
Bug 165342 is probably not a duplicate of this bug. It has to do with sub-menus, not menus and might be caused by kwin (I have just received a notice that the issue is reproducible on kwin, maybe with other applications).
Only affects kf5, not kf6. Already in 7.2. Not sure, if worth looking into, if kf5 is going away. Commercial support for Qt 5 is ending in a few months: https://endoflife.date/qt
(In reply to Callegar from comment #5) > Bug 165342 is probably not a duplicate of this bug. > It has to do with sub-menus, not menus and might be caused by kwin (I have > just received a notice that the issue is reproducible on kwin, maybe with > other applications). Well, the effect is the same anyway.
This is probably the same issue as bug 165409. The point here, is probably not that of a misplacement, but that the menu becomes a "regular window" (this is quite evident from the screenshot where the menu gets the window title "soffice.bin"). Once the menu is a regular window, the window manager starts positioning it according to its rules, which generally is in the middle of the screen. This issue is a REGRESSION, and should be marked as such. LibO 24.2 does not have the issue. Cannot say about 24.8 that I am not using because it regressed wrt to 24.2 on the gallery and for some reason there seems not to be a no-regression policy, so regression remain there across multiple development cycles. The issue is easy to reproduce. - click on a menu entry to open the menu: the menu opens regularly. - slide the mouse to the menu entry on the side: the menu for this other menu entry opens as a titled window. The issue Component should probably be UI, not graphics stack.
(In reply to Buovjaga from comment #7) > (In reply to Callegar from comment #5) > > Bug 165342 is probably not a duplicate of this bug. > > It has to do with sub-menus, not menus and might be caused by kwin (I have > > just received a notice that the issue is reproducible on kwin, maybe with > > other applications). > > Well, the effect is the same anyway. No, it is not: in this case the menu gets a window title. It is not a misplacement problem: the problem is that the menu becomes a regular application window.
(In reply to Callegar from comment #9) > (In reply to Buovjaga from comment #7) > > (In reply to Callegar from comment #5) > > > Bug 165342 is probably not a duplicate of this bug. > > > It has to do with sub-menus, not menus and might be caused by kwin (I have > > > just received a notice that the issue is reproducible on kwin, maybe with > > > other applications). > > > > Well, the effect is the same anyway. > > No, it is not: in this case the menu gets a window title. It is not a > misplacement problem: the problem is that the menu becomes a regular > application window. No, bug 157133 is not about getting a window title, but about misplacement. You said in bug 165409 that 24.2 was fine, but this was reported for 7.5.
*** Bug 165409 has been marked as a duplicate of this bug. ***
> No, bug 157133 is not about getting a window title, but about misplacement. Yes, from the title of this bug it is so. However, if you look at the screenshot attached to show the problem, https://bugs.documentfoundation.org/attachment.cgi?id=189411, then it is evident that the menu is getting a window title. As soon as an item appears to the window manager as a "regular" window, then the window manager kicks in applying its positioning rules (which generally are either to position at the center or to position where there is less overlap to other windows). The misplacement is likely a consequence of the fact that the menu is created in a wrong way, then appearing as a regular window to the window manager.
> You said in bug 165409 that 24.2 was fine, but this was reported for 7.5. My bad, you are right. Version 24.2 looked fine to me just because 24.2 is started by default with the KF6 VCL, while the versions I am getting from upstream LibO get by default started with the KF5 VCL. So 165409 is not a regression, but an issue of KF5 that is fixed in KF6
Looks like the pre-release binaries (rpms or debs) do not contain the kf6 VCL plugin at all, so it is actually hard to test that for me.
This is most likely a Qt issue, see tdf#148019. FWIW, I can't reproduce with a current development build on Debian testing (with plasma-desktop 4:6.3.0-1, kwin-wayland 4:6.3.0-2, libqt5core5t64:amd64 5.15.15+dfsg-4). (In reply to Callegar from comment #8) > This issue is a REGRESSION, and should be marked as such. LibO 24.2 does not > have the issue. Cannot say about 24.8 that I am not using because it > regressed wrt to 24.2 on the gallery and for some reason there seems not to > be a no-regression policy, so regression remain there across multiple > development cycles. If you think it's a regression, providing a bibisect result [1] to identify the commit introducing the regression would be useful. (If the underlying issue is actually a Qt issue, then there might not be much we can reasonably do on LibreOffice side, however.) Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 31d4a7bd3760ecb087c61cd6ae5095493820d230 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded [1] https://wiki.documentfoundation.org/QA/Bibisect/Linux *** This bug has been marked as a duplicate of bug 148019 ***
(In reply to Michael Weghorn from comment #15) > If you think it's a regression, providing a bibisect result [1] to identify > the commit introducing the regression would be useful. > (If the underlying issue is actually a Qt issue, then there might not be > much we can reasonably do on LibreOffice side, however.) Please ignore that, your comment 13 already clarifies it's not a regression.