Procedure to demonstrate the bug. 1. Open a Writer document 2. Set style to Heading 1 and insert a string 3. Find and Replace, check "Paragraph Styles" 4. Use drop down box in Find, select "Heading" 5. "Find Next" Actual behavior: "Search key not found" Expected behavior: "Finds Heading 1" (alternatively, Heading does not appear at all) Additional information: 1. If another string is added, with its style set as Heading, then it will be found with this procedure (but Heading 1 will not be found). (It could be useful to be able to search on Heading and find all Headings (regardless of level) 2. Same effect/bug can be achieved with other hierarchical styles (e.g., "First Line Indent" will also introduce "Text Body" into the drop down box, but will not find anything if searched (unless a Text Body style has actually been applied). 3. Because "Default Style" is the presumably the top parent, it always shows up in the dropdown box. But it is only found if the Default Style paragraph style is actually applied to a string. (a little confusing) tested with 6.3.3.2 and 6.4.0.0.beta1
I confirm that behaviour with Version: 6.3.4.2 (x64) Build-ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded List in Find & Replace shows all applied styles (including parent styles) cc: Design-Team for further input
"Heading" is not "Heading 1". You also have Default as another parent in the selection likewise it's the fact for the styles & formatting tab at the sidebar when you filter for "Applied Styles". Thing is, "Heading 1" is derived from "Heading" which is children of "Default", which would be shown when the filter combines with the hierarchical view. Guess it's some effort to suppress the parents in the F&R dialog but keep at the sidebar, though disabled there. What do you think, Mike?
(In reply to Heiko Tietze from comment #2) No idea how to fix this right now; just a quick code pointer to anyone who wants to fix this (I don't think it's an easy hack though): SwStyleSheetIterator::First in sw/source/uibase/app/docstyle.cxx populates the list - see `rDoc.IsUsed(*pColl)` call which checks if the style is used. Currently it returns true for any style that is used, even indirectly. Either the method should take a flag like "bUsedDirectly", or a check should be added later on used styles when only directly used styles are requested.
So let's keep the topic alive. The search dropdown should list only those styles that are used in the document and not (unused) parents. The replace dropdown contains the full list and allows to pick one of the not-yet-used styles, which is the intended workflow.
(In reply to Heiko Tietze from comment #4) > The search dropdown should list only those > styles that are used in the document and not (unused) parents. Sounds right. Consider to rename top the level “Default Paragraph Style” One reason is that there are also “Default Style” for Character Styles and Page Styles. As far as I can tell, there is not a “super” Default Style (that links together the Paragraph, Character, and Page styles together in a single “Default Style). Another reason is to highlight/emphasize that all the other paragraph styles are “built” on top of the “Default Paragraph Style” Maybe this point is also relevant to the "Standard" discussion in bug #128469. For example, if there was a "Default Paragraph Style" or a "Standard Paragraph Style", then it might make sense for the button in the Paragraph Style Dialog box to be "Default" or "Standard" (to be consistent with the name of this style).
(In reply to sdc.blanco from comment #5) > Consider to rename top the level “Default Paragraph Style” Good idea, file bug 129568 about this.
(In reply to Mike Kaganski from comment #3) > Either the method should take a flag like "bUsedDirectly", or a check should > be added later on used styles when only directly used styles are requested. Let's implement the "bUsedDirectly" flag. Please help me on how to determine if a style is directly applied or not.
Dear Shivam Kumar Singh, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
Dear sdc.blanco, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still present in Version: 7.3.5.2 (x64) / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL I'm not sure, but I think list of PS is the same list, that is displayed in navigator if choosing "Applied Styles".
Also in: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 41139aa86ecbb4c34e9996eb0f95a194b8eb0771 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL (In reply to Dieter from comment #10) > I'm not sure, but I think list of PS is the same list, that is displayed in > navigator if choosing "Applied Styles". If you mean "Styles Sidebar", then I have the same impression (i.e., the Applied Styles shown in the Styles Sidebar are the same shown in the Find dialog). Good observation.
(In reply to sdc.blanco from comment #11) > If you mean "Styles Sidebar", Yes.
Still the same with Version: 24.8.1.2 (X86_64) / LibreOffice Community Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL threaded Steps: 1. open an empty document 2. Change PS of first parapgraph to Heading 1 3. Edit -> Find & Replace 4. Enable Paragraph Styles and look at list in Find field Actual result Default Paragraph Style Heading Heading 1 Expected Result Heading 1