Description: Before version 7.2.2.2, detached tool bars could be moved, and closed by the "X" in the upper right corner. That is no longer the case with version 7.2.2.2 Steps to Reproduce: 1. If no tool bar is detached, detach a tool bar. To detach a tool bar, ensure that menu/display/tool_bars/block_tool_bars check box is unchecked. (The English may be somewhat different. French is menu/affichage/barres d'outils/bloquer barres d'outils.) 2. With the mouse, try to move the tool bar. It may move for a moment, to be subsequently fixed in place. 3. With the mouse, click on the "X" at upper right of the tool bar. No effect. 4. with the menu, close the tool bar. Then reopen. It displays in the same location. The mouse can not move or close the tool bar. Actual Results: See above. Expected Results: The tool par can be readily moved and/or closed with the mouse. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.2.2.2 Build ID: 20(Build:2) CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: fr-CA (fr_CA.UTF-8); UI: fr-FR Calc: threaded Built by Mageia (Linux) A recent update to 7.2.2.2 showed the problem. No problem before the update. Resetting the profile had no effect, except that it required undoing full screen and unclicking menu/display/tool_bars/block_tool_bars to be able to confirm the problem with a new profile. Since I have considerable customization of my profile, it is important to keep most of the configuration of my profile. However, for my tests, only the 2 changes indicated were made to the default profile.
I cannot confirm the problem. I have tested it with Version: 7.2.2.2 (x64) / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Confirmed. Can't select an action on these Toolbar buttons via their label. Version: 7.2.2.2 (x64) / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Only the button with icon performs the action. Workaround for the dialogs linked to the radiobutton is to select another value, then the dialog is again exposed with the custom RB.
Can not confirm, the undocked TB can all be moved and can be closed with the X on the TB frame. Version: 7.2.2.2 (x64) / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Maybe it only affects the Linux version ? I can't test an ms windows version. Comment 2 refers to buttons with icons. Note that on my (Linux) system, what does not work : 1) moving the tool bar (with the mouse on the title) 2) closing the tool bar via the X on the title Everything else works, including that showing the context menu. I just noticed that the context menu of the tool bar has a option to close the tool bar, which does work. However there is no option to move the tool bar. In my case, the tool bar is OUTSIDE the Libreoffice window. (It has to be for my use.) Have the other users tested that ?
(In reply to andréb from comment #4) > Have the other users tested that ? Yes, I have tested moving with mouse on title bar and closing by X on title bar.
No repro in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ec76fff198323122bedc63ffdfd896c2543102c6 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: fi-FI Calc: CL or Version: 7.2.2.2 (x64) / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: fi-FI Calc: CL Tested also with the toolbar outside the LibreOffice window but still no repro.
Changed OS to Linux since it doesn't seem to affect Ms Windows. Also noted that some of the buttons in the tool bar work sometimes but not always. It seems to depend on the cell(s) selected. Particularly Bold, left/centre/right, up/middle/down. But it could affect other tool bar buttons. I reset the tool bars again, just to be sure. Same symptoms.
I meant reset the profile. It is the third time I reset the profile since encountering the problem. (I keep the reset profiles, as well as returning to my original configuration.) The method of using the safe mode to test doesn't work, since in safe mode the tool bars can't be detached.
Reproduced with gtk3 only. Bibisected with linux-64-7.1 to https://git.libreoffice.org/core/commit/10367c3a583e962dbb0df5b81846f702f4180097 don't need to treat floating toolbars differently for set-focus Adding Cc: to Caolán McNamara
Buovjaga or andreb, could you try to retest this bug on gtk3? I can close the moving toolbar with the x from the corner. Version: 7.3.0.0.beta1+ / LibreOffice Community Build ID: 81b26582ed62db40e2be701ddefede7d8230d0d2 CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
(In reply to BogdanB from comment #10) > Buovjaga or andreb, could you try to retest this bug on gtk3? I can close > the moving toolbar with the x from the corner. Ok, I should have mentioned this: if you switch focus away from LibreOffice and back again, you can close it. But I would be suprised to hear that you can move the toolbar.
Created attachment 176701 [details] video Video for my case Version: 7.3.0.0.beta1+ / LibreOffice Community Build ID: 81b26582ed62db40e2be701ddefede7d8230d0d2 CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
I installed libo 7.3 beta, and the problem still exists there. But as Buovjaga said, if the focus is switched away from libo and back, the toolbar can be closed. (By both the x in the corner and the submenu.) But the toolbar still can't be moved. (Clicking on the toolbar and moving the mouse sometimes moves the toolbar momentarily, before the toolbar jumps back to it's initial position.) This is true for libo 7.2.2.2 as well. This problem was first seen just after the installation of 7.2.2.2. Was it caused by a different manner of interacting with gtk3, or by coincident something changed in gtk3 at more or less the same time ? I haven't noticed any other problems with apps using gtk3. What features of gtk3 are used to move the toolbars with the mouse ?
I can't reproduce (under X11) with gtk3-3.24.30, what version of gtk3 is in use in the affected system to rule that in or out as an issue
(In reply to Caolán McNamara from comment #14) > I can't reproduce (under X11) with gtk3-3.24.30, what version of gtk3 is in > use in the affected system to rule that in or out as an issue Under X11, gtk is 3.24.30+90+g20be04f7ac-1
under X11, I have gtk3-24-24 (revision 1.mga8), the latest stable version of X11 on Mageia (Linux)
that is, the lastest version of gtk3 available on the latest stable release of Mageia. The development version of Mageia does have gtk 3.24.30 or higher, but generally it won't install on the stable version without corrupting the system.
I encountered this as well, and can consistently repro with the Color toolbar, steps: - Open a document with an image, eg. attachment 180049 [details] from bug 149023, - Click on an image to select it, - On the Image toolbar, click the Color button (last one), which brings up a panel with settings, - Click on the panel, and then the closing [X]. => Nothing happens. Same if you try to move it.
repro 25.2+ (I used comment 18's reproduction steps)