Description: Double-click AutoFill behavior is inconsistent (and probably incorrect in some cases) when some rows are hidden. Steps to Reproduce: 1. Enter random data into the column A. 2. Add data to some rows in the column B. 3. Hide rows with data (and a few without) in the column B. 4. Put data into the column B in the cell right above any hidden row(s). 5. Double-click the handle. 6. Repeat with different cells (that are right above hidden rows). Actual Results: Depending on hidden cells in the column B, results may wary: 1. If hidden cell below the "origin" cell is empty, expected behavior is observed - visible cells are filled down to last row with data in the column A. 2. If hidden cell below the "origin" cell is not empty, and the first visible cell after the hidden row(s) is not empty, expected behavior is observed - all consecutive non-empty cells are filled down. 3. If hidden cell below the "origin" cell is not empty, but the one after it is empty, AutoFill fails. 4. If there are two hidden cells below "origin" cell that are not empty, different behavior is observed - AutoFill works, but ignores the column A, and fills cells down to bottom of the sheet (could be resource heavy). Expected Results: AutoFill should work on all visible cells the same way it works on cells if there are no hidden rows. Reproducible: Always User Profile Reset: No Additional Info: Notice that problem occurs when a hidden cell right below the "origin" cell has data.
Created attachment 162393 [details] testcase 1. Put anything into the green cells in column B and double-click the handle. 2. Expected behavior is observed - visible cells are filled down to row 21. 3. Revert changes, put anything in cell B10 or B13 (red) and double-click the handle. 4. AutoFill fails. 5. Revert changes, put anything in cell B17 (red) and double-click the handle. 6. AutoFill works, but ignores columns to the left and right, and fills all cells in a sheet down to the bottom row.
So I was trying a few situations based on the testcase. I was initially confused what it meant by double-clicking the handle, but I found highlighting the column and dragging it to the other columns worked just as well as manually inputting it in. Turns out the autofill varies depending on context: dragging it in means it works with the B17, but manual does not. Might do some additional testing but anyone can help. Version: 7.1.0.0.alpha0+ Build ID: 52820b52b3bca45e2db527d1cc5f4488b2e0b9d0 CPU threads: 8; OS: Mac OS X 10.15.6; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I just noticed that no rows are hidden in the test file - before doing anything hide the rows marked with "x"s. Tried on 6.2.2.2 version of LO, seems to be working correctly. Updated my LO to 6.4.6.2 - bug is still reproducible. (In reply to sora34ce from comment #2) > So I was trying a few situations based on the testcase. I was initially > confused what it meant by double-clicking the handle, By "handle" i meant a fill handle (that bit in the right bottom corner of the selection). > but I found highlighting the column and dragging it to the other columns worked just as > well as manually inputting it in. I'm not sure what you tried to do by highlighting and dragging the whole column. Columns A and C are there just so AutoFill knows how much it should fill. > Turns out the autofill varies depending on context: dragging it in means it > works with the B17, but manual does not. Might do some additional testing > but anyone can help. Again, i'm a bit confused by your words. What are you dragging (dragging "it"), and what do you mean by "manual"?
(In reply to Dmitry T. from comment #3) > I just noticed that no rows are hidden in the test file - before doing > anything hide the rows marked with "x"s. > > Tried on 6.2.2.2 version of LO, seems to be working correctly. > Updated my LO to 6.4.6.2 - bug is still reproducible. > > (In reply to sora34ce from comment #2) > > So I was trying a few situations based on the testcase. I was initially > > confused what it meant by double-clicking the handle, > By "handle" i meant a fill handle (that bit in the right bottom corner of > the selection). > > > but I found highlighting the column and dragging it to the other columns worked just as > > well as manually inputting it in. > I'm not sure what you tried to do by highlighting and dragging the whole > column. Columns A and C are there just so AutoFill knows how much it should > fill. > > > Turns out the autofill varies depending on context: dragging it in means it > > works with the B17, but manual does not. Might do some additional testing > > but anyone can help. > Again, i'm a bit confused by your words. What are you dragging (dragging > "it"), and what do you mean by "manual"? In response to all this: By "it" I mean the column, and by "manual" I mean click and drag. Also, I somewhat misunderstood the whole thing in response to dragging the column to autofill.
I also just realized autofill only works on numbers, so I tested and the bug works on the current version. Version: 7.1.0.0.alpha0+ Build ID: 52820b52b3bca45e2db527d1cc5f4488b2e0b9d0 CPU threads: 8; OS: Mac OS X 10.15.6; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
The filling behaviour was changed to match Excel's relatively recently. Can you test with 7.1? I can't find the report now.
It also seems inconsistent if adjacent rows are "Grouped" [MENU Data>Group and Outline>Group - F12] with the outlined rows (or columns)remaining blank when "concealed" or filling when "exposed" I expected the "grouping" behaviour to be something different to the "hide" behaviour as the inference is that they are not the same function. To remind you - Grouped columns or rows have a little "handle" to expose or conceal them whereas "show" requires selection of the "bounding" columns and "context menu" - show columns. The above step will also expose "grouped concealed" columns
137774 Appears to be a duplicate of this - My Bad
Dear Dmitry T., This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
@Buovjaga Oops, was planning to respond, but it slipped my mind at some point, sorry. Just checked on LO 7.1.6.2, the test case file gives me the same result as in comment #1. I also had a chance to check out behavior of AutoFill in Excel 2019 (build 2110), turns out it's not affected by hidden rows at all. If we go by comment #1's steps, at step 3 AutoFill will set cells B11/B14 and stop, and at step 5 it will set both B18 and B19, and stop. In LO, on the other hand, AutoFill does not set hidden cells. Actually, turns out there is also a problem with manually filling cells by dragging the handle across the hidden row - in Excel it sets hidden cells, but in LO they remain unchanged. So, the question we first need to answer is, which behavior is actually expected - should hidden cells be filled (as they do in Excel), considered a stop (as cells B11/B14 do in LO) or ignored completely (as cells B18 and B19 do in LO (but in such case AutoFill should honor the neighboring columns))?
I can repro (mostly) in Calc 7.2.2.2. Here's another explanation: A blank cell will stop further expansion when using double-click auto-fill, so filling stops before that blank cell. Expected behavior would be that a HIDDEN blank cell does not count when stopping double-click expansion. However, since a hidden blank cell WILL stop double-click expansion, this makes it look like double-click expansion is "stopping short" or just not working at all. Meanwhile, drag-down auto-fill seems to work as expected; a blank hidden cell does not affect expansion. This behavior could be completely disregarded as just the nature of double-click expansion, except that when expanding multiple columns at once all columns stop short if any column has a blank hidden cell in the expansion path. So, it boils down to this "as if": Double-click auto-fill acts as if it has only one variable for stopping, which is set according to the first blank cell encountered, hidden or not, in any column being expanded at once. Should double-click auto-fill instead act as if it had an array of stopping points applied separately to each of the columns being expended at one time?
(In reply to Joshua Coppersmith from comment #11) > So, it boils down to this "as if": Double-click auto-fill acts as if it has > only one variable for stopping, which is set according to the first blank > cell encountered, hidden or not, in any column being expanded at once. > Should double-click auto-fill instead act as if it had an array of stopping > points applied separately to each of the columns being expended at one time? Thanks for the summary, let's ask UX team
(In reply to Joshua Coppersmith from comment #11) Thanks for trying to convey my point (as i'm, surely, not doing it well enough myself, due to not being native English speaker), but, to be honest, it feels that your explanation is not entirely correct or on point. > Expected behavior would be that a HIDDEN blank cell does not count when > stopping double-click expansion. As i mentioned earlier, is it really an expected behavior? Should LO have it's own (consistent) behavior, or do the same thing Excel does? When i reported this issue, i didn't consider Excel at all, and based "expected" (by me, that is) behavior on drag-down fill, but now i think that the way it works in Excel actually makes more sense. I mean, consider how formulas work - if you copy a formula that references a row above into a cell right below the hidden row, it will reference a hidden row above, not the visible row. I think, AutoFill should act the same. > However, since a hidden blank cell WILL > stop double-click expansion, this makes it look like double-click expansion > is "stopping short" or just not working at all. That is correct, but i should mention, that empty cell will stop double-click expansion before ALL hidden rows, not just the hidden blank cell. SO, if, among 10 hidden rows, there are 9 cells with data, and 10th cell is blank, no hidden cell will be replaced. > This behavior could be completely disregarded as just the nature of > double-click expansion, It cannot be disregarded yet, as there still exists inconsistent behavior: 1. If all hidden cells are NOT blank and cells below hidden rows ARE blank, double-click expansion will suddenly start filling blank cells until it hits a non-blank cell or the bottom of the sheet (and latter could be performance heavy), while ignoring neighboring columns. 2. If there is only a single hidden row with a NON-BLANK cell AutoFill does nothing instead, which makes no sense at all. > except that when expanding multiple columns at once > all columns stop short if any column has a blank hidden cell in the > expansion path. Now, behavior for multiple columns is also a point of concern (good call), but, again, i think it should be first agreed on whether LO should have it's own behavior, or mirror Excel's one. In Excel (and in LO without hidden cells) behavior is that all cells are filled down as long as all cells are the same (all blank or non-blank). Considering all that, summary you gave is kinda moot.
Confirming the bug. Cells with content in the fill direction define the range, otherwise surrounding columns. If the filled cells are hidden the whole sheet is filled. Tested with Version: 7.2.2.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 7.2.2-2 Calc: threaded and Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: 829ea811e19fead7ad35049342136b592077674b CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded The dependency to grouping is unclear and should IMO discussed separately.