Created attachment 45172 [details]
Step 1

Created attachment 45173 [details]
Step 2

Created attachment 45174 [details]
Step 3

Created attachment 45175 [details]
Step 4 - Correct Display

Created attachment 45176 [details]
Step 4 - Wrong Display

Kohei: Is that a regression, please?

No, this behavior has been the same, not a regression.  It hasn't changed between 3.3.x releases AFAIK.

But the intention I think is to keep the selection when there is a pre-selected range, if not, select the whole data range.

Meanwhile, the workaround is to insert an empty row at row 17.  Then the selection won't go beyond the data range.

That's true, such behaviour does not change between 3.3.x releases.  That's the reason why I keep 3.3.0RC3 because 3.3.0RC4 begins to have this problem.

I know the workaround trick but I don't like it because I used to do cost analysis in a big spreadsheet and I am worried manual insertion could cause trouble in messing up certain formulas among cells.

I would be highly appreciated if this bug could be corrected.

Thanks again for your attention.

(In reply to comment #7)
> No, this behavior has been the same, not a regression.  It hasn't changed
> between 3.3.x releases AFAIK.
> 
> But the intention I think is to keep the selection when there is a pre-selected
> range, if not, select the whole data range.
> 
> Meanwhile, the workaround is to insert an empty row at row 17.  Then the
> selection won't go beyond the data range.

(In reply to comment #8)

> I know the workaround trick but I don't like it because I used to do cost
> analysis in a big spreadsheet and I am worried manual insertion could cause
> trouble in messing up certain formulas among cells.

No it doesn't.  Insertion of cells should never mess up formulas.  If it does, please file a bug.

Well, I meant manual mistakes when I used functions like vlookup and forgot to put $ cell references.

(In reply to comment #9)
> (In reply to comment #8)
> 
> > I know the workaround trick but I don't like it because I used to do cost
> > analysis in a big spreadsheet and I am worried manual insertion could cause
> > trouble in messing up certain formulas among cells.
> 
> No it doesn't.  Insertion of cells should never mess up formulas.  If it does,
> please file a bug.

Well, I looked into this, and the change we inherited from OOo to always extend the data area was intentional (the change you saw during the 3.3 RC phase).  The bad news is that, this area of the code is pretty complex, and making small changes here and there will not solve this issue completely without the risk of introducing other weirdness.

So, I'd like to tackle this post 3.4.x.  I'm planning to clean up this area on master (for 3.5), so I'll take care of this then.

(In reply to comment #11)

Debugging is always not an easy task.  Thanks again for looking it into matter and I look forward to seeing this bug be closed in 3.5.

Cheers!

In LibreOffice Calc versions 3.3.4 and 3.4.2 I had a similar problem. If I create the table below

    |  A     |   B
  --+--------+----------------------+
  1 | Name   | Value                |
  --+--------+----------------------+
  2 | a      | 1                    |
  --+--------+----------------------+
  3 | a      | 3                    |
  --+--------+----------------------+
  4 | b      | 2                    |
  --+--------+----------------------+
  5 | a      | 5                    |
  --+--------+----------------------+
  6 | b      | 2                    |
  --+--------+----------------------+
  7 | Total  | =SUBTOTAL(9;B2:B6)   |
  --+--------+----------------------+

select A1:B6 and create a AutoFilter (Data -> Filter -> AutoFilter), the filter is created for the region A1:B7. In the OpenOffice 3.2.1, the AutoFilter works as expected, creating a filter for region A1:B6.

Still reproducable on Ubuntu 13.10 x64, LibreOffice Version: 4.2.0.1
Build ID: 420m0(Build:1)

Best regards,
Zeki

Repro.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58
Locale: fi-FI (fi_FI)

Comment on attachment 45171 [details]
Document to reproduce the problem.

Problem 1 - selecting Data > Filter.  Both "AutoFilter" and "More Filters" use "F" as the selection character.  I saw the "Hide AutoFilter" under the "More Filters" selection, but could not find how to invoke it.

Problem 2 - When "Standard Filter" is selected, it displays a Filter criteria panel that allows multiple rows of criteria to be entered, with different operators, fields, conditions, and values. Formerly, I could TAB to each column, and in the Values column, TAB once more to see the list of values and simple criteria, such as "Empty" or "Not Empty".  Now TAB does not advance to values list, and I need to click the selection arrow to see the list.

The issue is related to standard filter, not auto filter. Adjust summary accordingly.

Dear Developers

In the Calc version 6.4.2.2 the bug is still present. I noticed that even if one defines a range in Data -> Define range, when selecting Filter or AutoFilter the range is redefined automatically. I do not have the skills to go into more details, however as little as I have studied programming this may be the root cause for filtering not working properly. Is this issue still somewhere on the list?

for the Bug Hunting Session 7.0.0.0.a1+: 

bug still as described by the OP, 

It's an ambiguous decision: a normal - inexperienced - user would of course like automatic range selection and newly added data to be filtered or sorted as well, but the same - inexperienced - user would not like his column-totals or footnotes to be filtered or sorted. 

It is difficult for a more algorithmic than intelligent program to meet both requirements. 

I think there have been long discussions and lonely decisions about this ... 

Are my observations correct: 

sort considers in the following order: 

1. the current selection in the sheet, if it is larger than one cell, 

2. an "__Anonymous_Sheet_DB__0" - automatic database area - if it is left over from the previous creation of a filter and the focus is in this area, if this area is divided by empty columns or rows only contiguous areas are taken? (the 'anonymous' areas are never deleted but only redefined once they are on a sheet?) 

3. a defined 'data range' if the focus is in it, 

3a. overlapping database areas are evaluated a little bit strange, with focus in the first (older or upper or 'left') area this is selected, with focus in the overlapping area also, with focus in the second (newer, deeper or 'righter') database area both areas are combined?

4. otherwise sort itself defines a rectangular area bordered by empty cells, 

and if this includes only the one selected cell ... 

5. just sorts this one cell, 

6. sort has an option to 'sort by row' - horizontally - and then re-arranges columns instead of rows, 

whereas filters - all filters? -  

1. simply always according to sort-4. define a filter range by themself and ignore all specifications from the user? 

2. have no 'horizontal' option and therefore should neither evaluate tags 'table:orientation="column"' from the files nor handle parameters 'bByRow' or 'bByColumn' in the evaluations for the filtering (UI and basic / macros) or let them influence the field assignments? 

- puhhh that was long, is that described somewhere as 'target behaviour'? - 

my approach would be: 

- sort is much more user friendly than the filters, 

- sort should not consider the automatic data area, which is not intuitive or manageable for the user, 

and filter should either: 

- behave as sort, and respect the user's specifications, 

or: 

- have a query in the filter definition: 'which area do you want to edit? "defined" B3:F165, or "automatic" B2:H182'

but there may be more ideas, and they may become difficult once excel compatibility is taken into account?

*** Bug 85773 has been marked as a duplicate of this bug. ***

I can confirm that 
the bug was solved in linux Version: 7.6.3.2 (X86_64) / LibreOffice Community
Build ID: 29d686fea9f6705b262d369fede658f824154cc0

But is now again present in Version: 7.6.5.2 (X86_64) / LibreOffice Community
Build ID: 38d5f62f85355c192ef5f1dd47c5c0c0c6d6598b