If I apply the AutoFilter functionality to a cell range that has no header columns and filter out to display only blank values, the filter is then lost and the rows become hidden. Steps to reproduce: -Fill in random numeric values in some cell range. -Delete at least one cell in one column in some row other than the first one. -Add AutoFilter on that cell range *without* using the first row as headers. -Click the autofilter arrow on some column with at least one empty/blank cell. -Select only blank/empty values. Expected behavior: -Should maintain the filter (showing arrows) like it does when there is a heading column or when displaying non-blank values within the filter. Actual behavior: -The filter (arrows at the top row) disappears and the rows become hidden. Setup: LO 6.0.5.2 running on Linux (Debian buster/sid).
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 143403 [details] spreadsheet with non-working autofilter
Created attachment 143404 [details] short video reproducing the bug
(In reply to Xisco Faulí from comment #1) > Thank you for reporting the bug. Please attach a sample document, as this > makes it easier for us to verify the bug. > (Please note that the attachment will be public, remove any sensitive > information before attaching it. > See > https://wiki.documentfoundation.org/QA/ > FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help > on how to do so.) Added a sample document and a gif video showing how the bug happens. Note that using a header row in the autofilter prevents this behavior.
I can reproduce it in Version: 6.2.0.0.alpha0+ Build ID: 67f3063b7c334d4d5c59132d90b938671aad09f0 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded and back to LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 @Eike, I thought you could be interested in this issue...
confirm on Windows too Version: 6.4.0.0.alpha0+ (x86) Build ID: ca6df519a78e5bfc96030c916f242b86306194e5 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
still an issue in 7.0.0.0.a1+, afaics it's not 'the autofilter' being lost but 'only' it's representation on screen (the UI), as well the dropdown buttons are gone as the option <data - autofilter> looks unchecked, but the filtering is! applied correctly, and if you click again on the supposedly switched off option autofilter the filtration is removed in the same manner as if you had the buttons visible and unfiltered using them, (the option <menu - data - autofilter> and the checkbox for it's state on/off (a real checkbox in linux, i had difficulties to spot it in windows, indicator for on/off is the background of the filter symbol becoming a little darker) are a special issue, my impression is that they are only checked for filtering ranges 'with headers', and stay unchecked for 'without'? in lin as well as in win, intentional?) or with <data - more filters - reset filter> you get back the unfiltered state with autofilter applied and dropdown buttons visible, note that the disappearing of the dropboxes doesn't depend on filtering for 'empty', they are also gone sometimes when you filter for one of the random values, and mostly after replacing the rand() values with fixed values, note that the autofilter reacts differently depending on whether you activate it: - with or without a header row (mentioned in the OP), - on an automatically selected range or have previously defined a <data - define range>, - <data - define range> also differentiates between with or without column headers, see options, - it even makes a difference if an automatically defined area has ever been used on a sheet, my experience is that the 'anonymouns database area' is never deleted but only changed after it's first use, and it partly influences the filters operations, - the filter also acts differently if you filter or sort, i have even seen the dropdown buttons from the top row appearing in cells somewhere down in the list after sort, when working on this area one should pay attention to a consistent user interface, it might be relevant when programming to note #132488, different results before and after save-load cycles can be quite confusing ... my testing with: Version: 7.0.0.0.alpha1 Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded and with the same ver. for win
autofilter also acts differently depending on the data provided, e.g. with a literal or alphanumeric 'header row' (a, b, c or a1, b2, c3), numeric data below that, and no predifined ranges: 'contains header' is automatically assumed and applied without asking the user, thus preventing to produce the situation of the OP
Reproduced with: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: de7356c2e0cb099fac396808b5a86a0393b48e5f CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-14_22:38:17 Calc: threaded Changing title as it is not required to select a blank value to reproduce. Steps: 1. Fill a range with numbers in a single column 2. Select said range 3. Data > AutoFilter 4. Answer "No" when asked about using the first line as a header 5. Click the AutoFilter dropdown, deselect the first value, click "OK" Result: the AutoFilter dropdown disappears. I'm wondering what would be a preferred solution: - Always enforce headers for AutoFilter? or - Move autofilter dropdown menu to the first visible cell in the AutoFilter range? (Which means you end up with an AutoFilter dropdown menu that is technically below the top of the range.)
(In reply to stragu from comment #9) > Reproduced with: > > Version: 7.3.0.0.alpha0+ / LibreOffice Community > Build ID: de7356c2e0cb099fac396808b5a86a0393b48e5f > CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: > 2021-06-14_22:38:17 > Calc: threaded > > Changing title as it is not required to select a blank value to reproduce. > > Steps: > 1. Fill a range with numbers in a single column > 2. Select said range > 3. Data > AutoFilter > 4. Answer "No" when asked about using the first line as a header > 5. Click the AutoFilter dropdown, deselect the first value, click "OK" > > Result: the AutoFilter dropdown disappears. > > I'm wondering what would be a preferred solution: > - Always enforce headers for AutoFilter? or > - Move autofilter dropdown menu to the first visible cell in the AutoFilter > range? (Which means you end up with an AutoFilter dropdown menu that is > technically below the top of the range.) I'd expect the dropdown arrow to remain at the top row.
This is somewhat related to bug 118625: the AutoFilter button should always stay at the top of the AutoFiltered range, regardless of its sorting or its filtering. Still the case with: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 24087697d5cf78aac346d4dcea0596373e15a95c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Dear david.cortes.rivera, 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