Bug 140745 - AutoFilter dropdown doesn't show (empty) on top of the list with values
Summary: AutoFilter dropdown doesn't show (empty) on top of the list with values
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.0.3 release
Hardware: All All
: medium normal
Assignee: Tünde Tóth
URL:
Whiteboard: target:7.2.0
Keywords:
Depends on:
Blocks: AutoFilter
  Show dependency treegraph
 
Reported: 2021-03-01 20:43 UTC by Johannes
Modified: 2021-06-04 18:46 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Example file (10.49 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-03-01 20:45 UTC, Johannes
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes 2021-03-01 20:43:09 UTC
Description:
AutoFilter dropdown doesn't show (empty) on top of the list with values, but between the last number value and before the first text value.

Steps to Reproduce:
1. Make a column with a headline, filled some cells with numbers, and some celss with text data
2. Click AutoFilter
3. Click on the down arrow of the filter in the headline

Actual Results:
The checkbox with (empty) is between the last number value and before the first text value.

Expected Results:
The checkbox with (empty) should be on top of the list with values.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
-
Comment 1 Johannes 2021-03-01 20:45:08 UTC
Created attachment 170161 [details]
Example file

Example file
Comment 2 Xisco Faulí 2021-03-02 09:10:26 UTC
I've checked with previous versions and it has been like this forever.
Could you please explain why should (empty) be on top ?
Comment 3 Johannes 2021-03-02 14:15:05 UTC
Because in all other cases, (empty) is always on top - I believed. But now I see, that (empty) is always under number values, but always above text values, also when there aren't mixed values (both number and text).
Thus maybe the bug report should be: (empty) should always be on top of the list of values, both if there are mixed values and if there are only number values (as is the case with text values).
I think, because (empty) is a special 'value' this should always on top. Consider (empty) as null, but now it is sorted on the (.
Comment 4 Xisco Faulí 2021-03-02 14:17:37 UTC
(In reply to Baggeraar from comment #3)
> Because in all other cases, (empty) is always on top - I believed.

Which other cases?
Comment 5 Johannes 2021-03-02 16:24:23 UTC
In case of only text values.
But in fact, (empty) isn't always the first result, but because of the ( it is most time the first result.
As said, because of (empty) is a very special 'result', in my opinion (empty) should always be the first result. Because it is not really (empty) as text string, but it should be considered as null. And that is consequently something different as the real results (numbers or text).
Comment 6 Roman Kuznetsov 2021-03-09 18:54:42 UTC
Confirm.

MS Excel place <empty> item always in bottom of the item list.

But I'm not sure that we should move <empty> item to top of the item list. I think it should be always in bottom as it is in MS Excel now
Comment 7 Heiko Tietze 2021-03-11 14:24:18 UTC
Let's move the "(empty)" entry to the top. 

Guess it's STR_EMPTYDATA, sorted with the other content in sc/source/core/data/documen3.cxx at sortAndRemoveDuplicates(). But I have no idea how to move this item on top of the list in an elegant way. And since sortAndRemoveDuplicates() is used a few times across the app, it might also have side-effects.
Comment 8 Johannes 2021-03-12 07:21:37 UTC
Note that maybe the same should be the case for '#N/A'.
These are the only two 'special' values, I believe.
Comment 9 Commit Notification 2021-06-01 11:04:37 UTC
Tünde Tóth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/361b95b39c0ad3028f82b9893bb3c84dcbd1932f

tdf#140745 sc AutoFilter: fix placing of "(empty)"

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 BogdanB 2021-06-04 18:46:38 UTC
(empty) is on top now

Verified in
Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: e96554b67b17f9d3d91b0bb1f29ab0b9cdc43dcb
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded