Created attachment 130396 [details] Spreadsheet with 2 diiferent filters set In a special spreadsheet document the filter via "Search items" doesn't find all corresponding cells. For demonstation I have attached in the zip-File a spreadsheet with 2 different filters set. - both spreadsheet documents contain the same data in 2 sheets, in both documents autofilter is activated in both sheets - in the sheet "Objektiv-Datierung" of both spreadsheets is set a filter in column G via "Search items" with search for "Tegonar", 40 rows are found The difference is the filter in column D in sheet "Altix III und IIIA" - in spreadsheet "Testtabelle_Filter_V1.ods" this filter is set via "Search items" with search for "Tegonar" too, 39 rows are found, row 34 is not shown - why? - in spreadsheet "Testtabelle_Filter_V2.ods" this filter is set via Standard Filter: Field name: "genaue Bezeichnung" (this is the title of column D), Condition: "Contains", Value: "Tegonar", all 40 rows are found When I'm right, the Standard Filter with condition "Contains" should deliver the same results as the filter via "Search items" - or am I wrong? This behavior I have first found in LO 5.3.0 RC1. Actually I have reproduced it with Version: 5.2.5.1 (x64) Build-ID: 0312e1a284a7d50ca85a365c316c7abbf20a4d22 CPU-Threads: 4; BS-Version: Windows 6.19; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group and with Version: 5.4.0.0.alpha0+ Build ID: 5e0e27e758e6f7fa325f36e6e51540e10bab0fdc CPU Threads: 2; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-01-12_23:44:54 Locale: de-DE (de_DE); Calc: group
Reproducible. Versión: 5.0.6.2 (x64) Id. de compilación: b3fbfa99158a1030fb79f0ba72b6851afc3c7895-GL Configuración regional: es-ES (es_ES) The source of the issue seems to come from the dots at the end of cell D34, they are three character dots while in D35 they are a single three dots character. Calc's options for regular expression doesn't seem to affect the behavior.
At first sight I haven't seen any differences between cell D34 and other cells in this column. But the hint to the trailing dots was good: This is the difference! After I have replaced the three single dots by a three dots character the filter via "Search items" works properly. For me the problem is resolved with this hint. But if it is not to complex it would be better when the filter function could be corrected.
Maybe a corner case, but it works improperly.
** 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 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 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 139121 [details] Screenshot of the filter list The Bug ist still present in LO 5.4.4 Version: 5.4.4.2 (x64) Build-ID: 2524958677847fb3bb44820e40380acbe820f960 CPU-Threads: 4; BS: Windows 6.19; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group and also in Version: 6.0.0.2 (x64) Build-ID: 06b618bb6f431d27fd2def25aa19c833e29b61cd CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL and Version: 6.1.0.0.alpha0+ (x64) Build-ID: facfc2951ea9f4745edd4a6fb1cf97697f33f40a CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2018-01-14_00:42:04 Gebietsschema: de-DE (de_DE); Calc: CL The first time the bug occured in LO 5.0.0, when in the filter entry list the the entry "empty" ("leer") was introduced - see in the attached screenshot. In LO 3 and 4 this entry was not present. One could filter the not empty rows only via "not empty" in the upper part of the filter list.
Dear Stefan_Lange_KA@T-Online.de, 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 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
As I have seen only now I haven't described the bug completely correct: The filter in "Testtabelle_Filter_V1.ods" is set via Standard Filter and 40 rows are selected by the filter and in "Testtabelle_Filter_V2.ods" is set by "Search items" and 39 rows are selected. But as was written by m.a.riosv in Comment 3 it is a corner case. I have already written in Comment 5 when the problem did occur first (LO 5.0.0, when in the filter entry list the the entry "empty" was introduced). The bug is still present in Version: 6.2.3.2 (x64) Build-ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL and in Version: 6.2.4.2 (x64) Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL and also in Version: 6.3.0.0.alpha1+ (x64) Build ID: 9e0e97b716ab074d4558c76a62a66bf597f332a5 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-21_17:40:06 Locale: de-DE (de_DE); UI-Language: en-US In Version: 6.3.0.0.alpha1+ (x64) there is an new bug I will report soon: In the case of "Testtabelle_Filter_V1.ods" where the filter is set via Standard Filter a click on the blue filter arrow in column D opens the entry list with all entries selected and also "All" selected, but the click on "OK" doesn't change the selection: Only the entries selected by Standard filter remain selected.
hello @Stefan, sorry, i had seen this long time ago, didn't i comment it or is the same problem mentioned elsewhere? not a solution, but a hint where to search ... the 'special thing' with your row 34, cell D34 is "...", vs. "…" in the other rows, see the difference? first is three single dots, second one special charakter sometimes called 'ellipsoid', it's easier to see here than with the font used in your sheet, but you can check by marking it with shift+cursor-keys, had a big big problem with ex$el some time ago, 'three dots' are sometimes a killing bug for spreadsheets, don't know why, but lost month of work til i spotted that ... :-( replacing the three dots with the ellipsoid 'heals' your file, would be nice if anybody can spill some clue about background, and why auto- and standardfilter reacted different ... and maybe prepare calc to never produce such errors ...
don't be astonished about funny results, prev. comment is a hint, not the solution, there is something more buggy, e.g. exchanging cell D34 and D35 will ... filter out row 34!!!, and giving row 35 an ellipsis symbol afterwards will heal the disappearing of row 34 on re-apply of the filter ... nice quirk ...
quite sure it's boiled down to autofilter not differentiating between "…" - 'ellipsis symbol', one character!, and "..." - 'three single dots', three characters, in selection definition, but as result only displaying those elements which first appear in the data, ommitting the 'nearly identical' ones with the other symbol(s), clear bug, ver. 3.5.1.2 could! handle them distinctive, regression, bibisect request, when trying to investigate you need to switch of app. replacement in [tools - auto correct options],
002E ; [*027E.0020.0002] # FULL STOP 2026 ; [*027E.0020.0004][*027E.0020.0004][*027E.0020.0004] # HORIZONTAL ELLIPSIS
(In reply to b. from comment #10) > quite sure it's boiled down to autofilter not differentiating between > > "…" - 'ellipsis symbol', one character!, > > and > > "..." - 'three single dots', three characters, > > in selection definition, but as result only displaying those elements which > first appear in the data, ommitting the 'nearly identical' ones with the > other symbol(s), clear bug, > > ver. 3.5.1.2 could! handle them distinctive, regression, bibisect request, > > when trying to investigate you need to switch of app. replacement in [tools > - auto correct options], Happens first in bibisect-41max, but couldn't do bibisect due to lots or other errors.
In the Testtabelle_Filter_V1.ods if I search for the term "Tegonar", row 34 is not shown in: Version: 6.3.6.2 (x64) Build-ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU-Threads: 16; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL and Version: 7.4.0.2 (x64) / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL If I refresh the filter via "Search items", I cannot reproduce the error in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b60dfc2928ef9763452c57f06073185456310609 CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL threaded Maybe someone can confirm the fix too?
Hello Andreas, many thanks for your test! I haven't watched the bug recently because it was minor important for me. Now I have tested again too and I can confirm your results: With these builds I can reproduce the buggy behavior: Version: 7.4.0.3 (x64) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 4; OS: Windows 10.0 Build 22623; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded and Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 4; OS: Windows 10.0 Build 22623; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded With these builds I can no longer reproduce the behavior: Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL and Version: 7.5.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 3aca23eec42e9d6fbe57071d7633ae1fc4bc5fcc CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded and Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9b46020c262045aed0beace4708565235c2523cc CPU threads: 4; OS: Windows 10.0 Build 22623; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded Means for me the bug is resolved and I would close it, but I don't know what is the correct status: Resolved fixed - or Resolved works for me because no solving patch is known?
After bibisecting this issue, it was solved by the following commit: https://git.libreoffice.org/core/commit/1b1ad0e3d5988c5e16dabfaa40252a22dab517b7
*** This bug has been marked as a duplicate of bug 125363 ***