Description: If you reach the search result for your word within your enumeration, the location of the arrow button to go to the next search result changes its location. Rather then going to the next search result, you click on some kind of formatting item on the enumeration list format bar. Steps to Reproduce: 1. Write a page full of text and use any kind of enumeration list 2. press CTRL + F to search for a word which is included in the text and also included in your enumeration (so your word must be > 1 times existing in your text) 3. use the arrow buttons to navigate between the search results (going to the next search result) Actual Results: If you reach the search result for your word within your enumeration, the location of the arrow button to go to the next search result changes its location. Rather then going to the next search result, you click on some kind of formatting item on the enumeration list format bar. Expected Results: Next search result arrow button has always same position so you can easily navigate without ENTER rather than doing formatting your enumeration by accident. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.0.2.1 (x64) Build-ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89 CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Created attachment 140941 [details] printscreen no repro with Version: 6.1.0.0.alpha0+ Build ID: 3102b8c8b52845ca4584579a7ad2154488943855 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: x11;
What do you mean by "enumeration list format bar"? Can you take a screenshot of the problematic result and attach it here? Press PrtScr on your keyboard and paste to some image editing software (like MS Paint) and use crop tool, if needed). I could not reproduce the problem either. Arch Linux 64-bit Version: 6.0.2.1.0+ Build ID: 6.0.2-1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the screenshot.
I talk about this two bars on the bottom of the Writer: see 'two_bars_screenshot.jpg'. Sometimes the bars move, depending on if you are inside an enumeration. So if you click on the next search result button, you could get into an enumeration. If you click again on the same position of your mouse - simply because you wanna go to the next result again - you click on the formatting option below just. This is hard to fix and I'm not sure how it is done better. If you still don't know what I mean, I have to try to describe it completely different. It's hard to explain to be honest.
Created attachment 140946 [details] these are the two bars I talk about
Ok, your terminology was confusing. So, clearer steps: 0. Activate View - Toolbars - Bullets and numbering and place it under the quick find bar (might need some fiddling) 1. Write a page full of text and use a numbered list somewhere in it 2. press CTRL + F to search for a word which is included in the text and also included in your numbered list (so your word must be > 1 times existing in your text) 3. use the arrow buttons to navigate between the search results (going to the next search result) I cannot reproduce the problem. I did run into this old annoyance: bug 38850. Arch Linux 64-bit Version: 6.0.2.1.0+ Build ID: 6.0.2-1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group
Reproducible for me with Version: 6.1.0.0.alpha0+ (x64) Build ID: 9d75bfcfaef97b247b3b6cd346eb27e02ae7b010 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-19_06:25:17 Locale: de-DE (de_DE); Calc: CL Thias happens, if 1) the bullet and numbering toolbar appears below the search toolbar or 2) the bullet and numbering toolbar disappears below the search toolbar, if you reach a search result in the text below the list. I don't know how to treat this issue. Is it a bug or an enhancement? Can it be solved? => SET to new, because I can confirm the observed behaviour.
I don't think it's a bug. the numbering toolbar appears because the search is on the list. Anyway, let the UX team decide...
This is no bug but it is not optimal if we talk usability.
Well, dynamic toolbars are odd. We will always run into trouble and the only way to avoid this is a completely new UI. The alternative is to have the search in the sidebar (there should be a ticket). Agreed with the problem but I don't see any feasible solution.
Maybe moving the toolbar to a vertical position can help, if it's Left to Right language, docked on the right next to the sidebar. And with the search toolbar docked at the bottom IMHO toolbars without fields, looks better docked in a vertical position.
Tested with Version: 6.3.0.0.alpha0+ (x64) Build ID: f42554a1886ebe49170c25096dc3281b2c7bb1f4 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-02-08_22:37:30 Locale: en-US (de_DE); UI-Language: en-US Calc: threaded Result: Bullets and Numbering toolbar appears above Search Toolbar. So I would say RESOLVED WORKSFORME. Clemens, please change it back to NEW, if you don't agree