Bug 55855 - The position of Find toolbar should stay fixed
Summary: The position of Find toolbar should stay fixed
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected) release
Hardware: All All
: medium minor
Assignee: Not Assigned
: 66128 91922 92808 92859 (view as bug list)
Depends on:
Blocks: Find-Toolbar
  Show dependency treegraph
Reported: 2012-10-10 21:40 UTC by stfhell
Modified: 2017-09-05 15:09 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:

Screenshot 1: find toolbar (86.39 KB, image/jpeg)
2012-10-10 21:41 UTC, stfhell
Screenshot 2: find toolbar over numbering toolbar (78.13 KB, image/jpeg)
2012-10-10 21:45 UTC, stfhell

Note You need to log in before you can comment on or make changes to this bug.
Description stfhell 2012-10-10 21:40:41 UTC
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.
Comment 1 stfhell 2012-10-10 21:41:39 UTC
Created attachment 68423 [details]
Screenshot 1: find toolbar
Comment 2 stfhell 2012-10-10 21:45:05 UTC
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".
Comment 3 Urmas 2012-10-11 13:25:19 UTC
So user can just put it in a convenient position. It's not a problem.
Comment 4 zathra_70 2012-11-07 21:24:40 UTC
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.
Comment 5 Jorendc 2013-02-10 17:33:16 UTC
(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 rc3 I set status to NEW.
Comment 6 Jorendc 2013-06-24 22:57:13 UTC
*** Bug 66128 has been marked as a duplicate of this bug. ***
Comment 7 eduard 2014-06-10 14:07:57 UTC
I can confirm this issue. Documents get changed accidentally when I just search through them using the mouse button.
Comment 8 Simo Kaupinmäki 2014-07-22 15:44:22 UTC
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.
Comment 9 Norbert X 2014-10-04 11:44:13 UTC
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>).
Comment 10 Gordo 2015-06-07 23:07:31 UTC
*** Bug 91922 has been marked as a duplicate of this bug. ***
Comment 11 Gordo 2015-07-21 18:21:08 UTC
*** Bug 92859 has been marked as a duplicate of this bug. ***
Comment 12 Gordo 2015-07-21 18:23:09 UTC
*** Bug 92808 has been marked as a duplicate of this bug. ***
Comment 13 QA Administrators 2016-09-20 10:18:37 UTC Comment hidden (obsolete)
Comment 14 tablerocker 2016-09-20 10:48:12 UTC
No change in behaviour, bug still exists.

LO Version:
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)
Comment 15 Norbert X 2017-09-01 17:03:14 UTC
Bug exists in 

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.
Comment 16 Yousuf Philips (jay) (retired) 2017-09-05 15:09:58 UTC
This has been fixed.

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.