Bug 105314 - EDITING autofilter mixes "…" - 'ellipsis symbol', and "..." - 'three single dots' and produces partial result | was: Filter finds not all cells
Summary: EDITING autofilter mixes "…" - 'ellipsis symbol', and "..." - 'three single d...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.0.6.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: Data-Filter
  Show dependency treegraph
 
Reported: 2017-01-13 18:39 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2020-09-06 18:48 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Spreadsheet with 2 diiferent filters set (68.71 KB, application/zip)
2017-01-13 18:39 UTC, Stefan_Lange_KA@T-Online.de
Details
Screenshot of the filter list (236.30 KB, image/jpeg)
2018-01-16 09:52 UTC, Stefan_Lange_KA@T-Online.de
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan_Lange_KA@T-Online.de 2017-01-13 18:39:55 UTC
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
Comment 1 m.a.riosv 2017-01-14 02:01:06 UTC
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.
Comment 2 Stefan_Lange_KA@T-Online.de 2017-01-14 11:01:12 UTC
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.
Comment 3 m.a.riosv 2017-01-14 20:24:41 UTC
Maybe a corner case, but it works improperly.
Comment 4 QA Administrators 2018-01-15 03:24:06 UTC Comment hidden (obsolete)
Comment 5 Stefan_Lange_KA@T-Online.de 2018-01-16 09:52:18 UTC
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.
Comment 6 QA Administrators 2019-05-21 02:53:48 UTC Comment hidden (obsolete)
Comment 7 Stefan_Lange_KA@T-Online.de 2019-05-21 21:46:53 UTC
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.
Comment 8 b. 2020-09-04 18:00:40 UTC
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 ...
Comment 9 b. 2020-09-04 18:21:30 UTC
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 ...
Comment 10 b. 2020-09-06 18:48:58 UTC
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],