Created attachment 42717 [details] Calc test file This bug was filed after this discussion: http://lists.freedesktop.org/archives/libreoffice/2011-January/005521.html R_ouellette found a bug in OOo 3.3 RC8 and reported it to them: http://www.openoffice.org/issues/show_bug.cgi?id=116164 He has attached a test case that trigger the problem, that i attached here too. He found that the bug was present on LibO 3.3.0rc4 too. Testing this problem on LibO 3.3.0 from Debian experimental using the test file, i've found different problem, so i decided to open this bug: - filter is slow: r_ouelette said OOo hangs forever (even if the subject says "crashes") if one filter "1" or "2" on the second column. It doesn't hang forever, it is only slow. Here takes about 4 minutes on a 1,6 GHz Pentium M. - filter is slow also on removing the filter: it take the same amount of time if i select "All" on the filter. - copy/paste of the filtered cells works. See: http://smurfonspreadsheets.wordpress.com/2007/04/30/1-million-rows/ - if i put the cursor on the first filtered cell and press SHIFT+CTRL+down_arrow to select them, the selected region is wrong: it ends at 67815 instead of 20481, so the region contains many empty cells. - when you filter "1", for example, you can see another strangeness: look at the filter.png image i've attached. The row number, jumps from 20480 to 57571. - The vertical scroll bar seems to go crazy if you try to drag it when "1" (for example) is filtered and you are near row 20480. Ciao. Cesare.
Created attachment 42718 [details] Row jump
(In reply to comment #0) > - when you filter "1", for example, you can see another strangeness: look at > the filter.png image i've attached. The row number, jumps from 20480 to 57571. > Ciao. > Cesare. This part is not a bug. You have a data range "Excel_BuiltIn_FilterDatabase_1" define as A1:B57571.
(In reply to comment #2) > This part is not a bug. > You have a data range "Excel_BuiltIn_FilterDatabase_1" define as A1:B57571. You are right: if i delete that data range, there is no more row jump. Sorry, i'm not familiar with the data range function, i haven't see this. Cesare.
This is related to two separate internal issues (row attribute storage and drawing layer), both of which I'd like to nail down for 3.4. I also briefly touched on this issue during my talk at FOSDEM just this week.
Ok. Fixed on master.