Bug 41835 - FILTER data range defined by LibO ends before last sheet row
Summary: FILTER data range defined by LibO ends before last sheet row
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.3 release
Hardware: Other All
: medium normal
Assignee: Kohei Yoshida
URL:
Whiteboard: BSA target:3.5 target:3.6
Keywords:
: 41836 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-10-16 09:34 UTC by baldinirobert
Modified: 2012-01-27 22:53 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample Document, see Comment 4 (144.28 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-10-24 10:55 UTC, Rainer Bielefeld Retired
Details
example (11.38 KB, image/jpeg)
2011-11-14 08:32 UTC, ribotb
Details

Note You need to log in before you can comment on or make changes to this bug.
Description baldinirobert 2011-10-16 09:34:55 UTC
Problem description:
When applying an autofilter to a column and filtering all column items by a single entry,
the result is not only all rows containing the selected entry but also some empty rows with
very high row index (i.e. 1048576)

Steps to reproduce:
1. Insert the text "show me" in the cell B2
2. Insert the text "don't show me" in the cell B3
3. Insert the text "show me" in the cell B4
4. Apply an autofilter to the column B and select "show me"

Current behavior:
Calc shows row 2 and row 4 with the text "show me" but also the row 1048576
with no text in cell B1048576.
When the Autofilter-option is set to "All" and then the option "show me" is reselected,
Calc shows also the empty row 1048573. Repeating this steps Calc continue to show
more and more empty rows.

Expected behavior:
The empty rows should remain invisible.

Platform (if different than the browser): 
              
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/534.51.22 (KHTML, like Gecko) Version/5.1.1 Safari/534.51.22
Comment 1 baldinirobert 2011-10-16 09:48:28 UTC
*** Bug 41836 has been marked as a duplicate of this bug. ***
Comment 2 Rainer Bielefeld Retired 2011-10-23 23:49:24 UTC
NOT reproducible with "LibreOffice 3.4.3  - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]" 

@baldinirobert@yahoo.it
Please attach a sample document!
Comment 3 GerardF 2011-10-24 09:31:23 UTC
(In reply to comment #2)
> NOT reproducible with "LibreOffice 3.4.3  - WIN7 Home Premium (64bit) German UI
> [OOO340m1 (Build:302)]" 
> 
Reproduce with LibreOffice 3.4.3 - Windows Vista.

To reproduce this bug, select the entire column and apply Autofilter.
The bug is not reproduce selecting only a part of the column.
Comment 4 Rainer Bielefeld Retired 2011-10-24 10:54:06 UTC
OS due to Comment 3

[Reproducible] with attached sample document and "LibreOffice 3.4.3  - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]" 

It seems that the filter data range "__Anonymous_Sheet_DB__" becomes smaller with every new filter action, what is the main problem.
Rows behind the last filter data range will be shown randomly after filter action.

@sumuthu:
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.

- Reported with Bug Submission Assistant -
Comment 5 Rainer Bielefeld Retired 2011-10-24 10:55:00 UTC
Created attachment 52703 [details]
Sample Document, see Comment 4
Comment 6 Jean-Baptiste Faure 2011-10-28 22:24:11 UTC
Same problem in Lib 3.4.4 RC1 and master under Ubuntu (10.04 x86_64)

I do not use very much filter feature, but perhaps thise bug should be added to the list of most annoying bugs for 3.4?

Best regards. JBF
Comment 7 Muthu 2011-11-02 02:48:13 UTC
@rainer: Can you verify once with the master builds as well, please?
I tried to reproduce the problem on master, but was not able to. Is it specific to 3.4, please?
Comment 8 Muthu 2011-11-02 02:50:14 UTC
Some anonymous db issues were fixed recently. Maybe this ones already fixed? I guess, this one is for kohei?
Comment 9 Rainer Bielefeld Retired 2011-11-02 03:15:09 UTC
> @rainer: Can you verify once with the master builds 

Both not up to date with source code:
[Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  d3d1481-3f8994a-2ba0a9f)]" (110909)

[Reproducible] with parallel installation of MinGW Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  2ba5d12-e8c71c5-41e7bcd-4b83b90)] (daily/MinGW_cross-compilation2011-10-25_00.12.09)"
Comment 10 Markus Mohrhard 2011-11-04 21:54:24 UTC
related to bug 42286, might be related to our unnamed db data work

@Kohei: let us see what Pierre achieves with in the other bug report, otherwise we can have a look at it again
Comment 11 ribotb 2011-11-14 08:23:29 UTC
Reproduce with LibreOffice 3.3.3 and 3.3.4 under Windows XP SP 3;
reproduce with LibreOffice 3.4.3 and 3.4.4 under Windows 7 SP1.

Bernard Ribot
Comment 12 ribotb 2011-11-14 08:32:16 UTC
Created attachment 53536 [details]
example
Comment 13 Kohei Yoshida 2011-11-30 17:44:16 UTC
Let's get to the bottom of this.
Comment 14 ribotb 2012-01-27 14:06:08 UTC
Hello,

I tested with the same spreadsheet shown in my attachment. It's now Ok (LO350rc2).

Bernard
Comment 15 Rainer Bielefeld Retired 2012-01-27 22:53:17 UTC
Works fine with "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit).

Very new fix, did not come automatically with new autofilter design. 3.5.0 Beta1 still showed the problem, no longer a problem with 3.5.0 Beta3

Also ok with  "LOdev 3.6.0alpha0+  English UI/Locale [Build ID: aa7e105-b2dd236-9eed775-d06f752-4dba2d1 (libreoffice-3-5-branch-point)]"  {Win-x86@9-Voreppe Win32 pull time 2012-01-13 18:31:30}. OS: German WIN7 Home Premium (64bit)  

So I close this Bug because I do not think that there is a plan to cherrypick the fix to 3.4.6?!