The new browser-like Find toolbar (Ctrl+F) is not realised as a floating window like the Find & Replace dialogue but as a toolbar docking in the main window over the status bar. From an ergonomical point of view, the toolbar solution is often a problem. Users typically press "Find Next" or "Find Previous" to browse through matches of the search string, using the mouse to press the appropriate button. The problem is that LibreOffice docks all sorts of toolbars over the status bar, depending on the context of the marked area (in Writer: numbering toolbar, table toolbar). If the "Find" text match is part of a numbering or table, these toolbars become visible and push the "Find" toolbar up. You have to move the mouse pointer to continue with "Find Next/Previous". If you wish to click through a number of matches, you constantly have to move the mouse in order to press the same button. (If you don't, you activate some button of the numbering or table toolbar.) (See attached screenshots of Writer.) The "Find" toolbar should not move around when it is visible, since you want to focus on the text area while browsing the "Find" matches, not on the toolbar.
Created attachment 68423 [details] Screenshot 1: find toolbar
Created attachment 68424 [details] Screenshot 2: find toolbar over numbering toolbar The mouse pointer has not been moved, but is over a different button: Clicking at the same pointer position that will select "Find Next" at screenshot 1 will now select "Insert unnumbered entry".
So user can just put it in a convenient position. It's not a problem.
I experience this problem constantly and it is very irritating when you are searching through long document in which the term you are searching for appears many times. I just want to keep clicking the next button while looking at the searched text. Having to stop, look at where the button has moved to, chase the button, click it in new position, repeat 30 times - - very aggravating as I often have to do this several times a day. It is too easy to click and find you have now reformatted or edited yet another table or a list without realizing it. As a usability issue, this is a 9 out of 10 imo.
(In reply to comment #3) > So user can just put it in a convenient position. It's not a problem. That doesn't resolve the issue when the findbar is docked at the bottom of the writer window. When a search term is in a list or table the corresponding toolbar will be placed under the findbar, therefore the findbar bumps up. Because this is already reproduced and I still can reproduce using Linux Mint 14 x64 LibreOffice 4.0.0.3 rc3 I set status to NEW.
*** Bug 66128 has been marked as a duplicate of this bug. ***
I can confirm this issue. Documents get changed accidentally when I just search through them using the mouse button.
Steps to reproduce: 1) Open (or create) a text document with both a normal paragraph and a list. 2) Open the Find toolbar (Ctrl+F) and use the Find Next/Previous button to find a word that appears both in the normal paragraph and in the list. When a word in the list is found, the Bullets and Numbering toolbar appears, pushing the Find toolbar upwards. When a word outside of the list is found, the Bullets and Numbering toolbar disappears and the Find toolbar is moved down again. Instead of keeping the focus on the text, you have to keep track of and repeatedly adjust to the changing position of the Find toolbar. As a simple fix you can manually change the position of the toolbars and, for example, anchor the problematically appearing and disappearing toolbar above the Find toolbar, but this should rather be the default and not something users have to figure out by themselves.
I can confirm this bug in 4.3.2. I'll copy my comment from https://bugs.freedesktop.org/show_bug.cgi?id=81475#c23 here: I think that dynamic appearance/disappearance of toolbars is not a good idea. For me it is comfortable to place toolbars once and use them when I want to use them, not contextually (current object- or action- dependent). But now in 4.3.2 toolbars disappear even if they have Lock Toolbar Position option checked. Please enable static toolbar positions. Popping toolbars may cause attention switch and may lower document author's productivity. Otherwise you will create another stupid, ugly, non-usable Ribbon/MFI. I think that many LibreOffice users would be happy with MS Office 2003-like interface. Users do not need bells and whistles, they need comfortable and customizable interface. This interface should allow users to place and pin (lock) toolbars as they want and use keyboard shortcuts for more productivity (for example, the fastest way to add Cross-Reference is to press <Alt-i><e>).
*** Bug 91922 has been marked as a duplicate of this bug. ***
*** Bug 92859 has been marked as a duplicate of this bug. ***
*** Bug 92808 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
No change in behaviour, bug still exists. LO Version: 5.1.5.2 Build-ID: 7a864d8825610a8c07cfc3bc01dd4fce6a9447e5 CPU-Threads: 4; BS-Version: Windows 6.2; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: CL Windows 8.1 (home)
Bug exists in Version: 5.4.1.2 Build ID: 1:5.4.1~rc2-0ubuntu0.16.04.1~lo0 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group Ubuntu 16.04 LTS with PPA.
This has been fixed. Version: 6.0.0.0.alpha0+ Build ID: fc61be93c60967bf1d6bcffcada8189016d4530e CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-05_00:50:38 Locale: en-US (en_US.UTF-8); Calc: group @Heiko, @Cor, @Stuart, @Thomas: do you guys agree with this fix, as I think the old behaviour of the find toolbar being at the top of the toolbars that appear at the bottom of the window is the better choice, as that ensures that the user has the least amount of mouse movement to utilize the toolbar. https://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/UI/WriterGlobalWindowState.xcu#106