Bug Hunting Session
Bug 75718 - function does not work Edit> Fill> Series> AutoFill
Summary: function does not work Edit> Fill> Series> AutoFill
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: All All
: medium critical
Assignee: Kohei Yoshida
URL:
Whiteboard: target:4.3.0 target:4.2.3
Keywords: regression
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2014-03-03 15:05 UTC by Roman Kuznetsov
Modified: 2014-03-08 09:58 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
gif animation (385.48 KB, image/gif)
2014-03-05 13:30 UTC, ape
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2014-03-03 15:05:35 UTC
to repeat, do the following:
1. enter text "January" in a cell (without the quotes)
2. select a range of cells, including the first text
3. go to Edit > Fill > Series of main menu
4. select the type of series AutoFill
5. Press OK

instead of the list in January February March April and so on we will see only January a blank cell in through

In the Quick Start Guide is written that:
"AutoFill – forms a series directly in the sheet. The AutoFill function takes account of customized lists. For example, by entering January in the first cell, the series is completed using the list defined in LibreOffice > Tools > Options > LibreOffice Calc > Sort Lists." - but it does not work!
Comment 1 Tomaz Vajngerl 2014-03-03 16:53:13 UTC
Confirming. AutoFill in general does not work correctly.
Comment 2 ape 2014-03-03 17:10:44 UTC
I confirm this bug. The function ‘Fill Series – AutoFill’ does not know how to use The Sort List (Tools – Options – LibO_Calc).
 This is a regression to LibreOffice 4.1.5, so the error status is critical.
--
OS: Windows XP (32 and 64 bit); LibODev 4.2.3.0.0+ (Build ID: 4274001144adeb0b0a1e7da05d52c1bedbe899e5, TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-02-27_08:31:36)

OS: Lubuntu 13.10 (64 bit); LibreOffice 4.2.2.1 (Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f)
--
1. Create a new spreadsheet.
2. Select multiple cells in any column.
3. Select the menu ‘Edit – Fill – Series..’
4. Select the option ‘AutoFill’ in The Series type.
5. Write 'Sun' (for example) in The Start value and click 'OK' button.
6. Cells are not filled with names of days of the week, one after another.
Comment 3 vlhown 2014-03-04 04:53:14 UTC
I confirm the bug too. It applies not only predefined lists but any series:
1. Fill first three cells in a column with 1, 3, 5.
2. Select the range in the column including first three cells.
3. Apply Autofill to selected range.
You expect to see a sequence of odd numbers but you get something else.
Comment 4 ape 2014-03-05 07:15:06 UTC
I confirm this bug for LibreOfficeDev 4.3.0.0.alpha0+:
Build ID: 4402efc18ae16e279d55858946d2c8b8972f3f9f
TinderBox: Win-x86@39
Branch:master
Time: 2014-03-04_00:54:43
OS: Windows XP sp2 64-bit Edition
Comment 5 ape 2014-03-05 13:30:12 UTC
Created attachment 95166 [details]
gif animation

Preview the animation please!
--
This function (AutoFill) works fine on the row, but it does not work, if you select a column. It is possible that the adding empty cell makes the block of the AutoFill’s work.
Comment 6 Julien Nabet 2014-03-05 21:28:10 UTC
Thank you Ape for having noticed this very interesting point!

I started from your example to know where the bug could be.

I noticed this:
http://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/docfunc.cxx#4430
nCount in OK/horizontal case gives 6
nCount in KO/vertical case gives 5
nCount seems to correspond to the number of cells to fill (after the one already filled by first value)

On gdb session, if line 4455 of this same file, I force the nCount value to 6. vertical case gets OK.
Comment 7 Julien Nabet 2014-03-05 22:07:54 UTC
Keeping on with debugging (trying to fill A1/A7), I got this bt :
#0  ScColumn::GetEmptyLinesInBlock (this=0x2aaacdf7b010, nStartRow=0, nEndRow=6, eDir=DIR_BOTTOM) at /home/julien/compile-libreoffice/libo/sc/source/core/data/column2.cxx:1238
#1  0x00002aaac8fd1ccb in ScTable::GetEmptyLinesInBlock (this=0x2aaacdf7b010, nStartCol=0, nStartRow=0, nEndCol=0, nEndRow=6, eDir=DIR_BOTTOM)
    at /home/julien/compile-libreoffice/libo/sc/source/core/data/table1.cxx:1012
#2  0x00002aaac8e2d346 in ScDocument::GetEmptyLinesInBlock (this=0x1602238, nStartCol=0, nStartRow=0, nStartTab=0, nEndCol=0, nEndRow=6, nEndTab=0, eDir=DIR_BOTTOM)
    at /home/julien/compile-libreoffice/libo/sc/source/core/data/document.cxx:5681
#3  0x00002aaac94a3a9f in ScDocFunc::FillSeries (this=0x1605840, rRange=..., pTabMark=0x16f0810, eDir=FILL_TO_BOTTOM, eCmd=FILL_AUTO, eDateCmd=FILL_DAY, 
    fStart=1.6999999999999999e+307, fStep=1, fMax=1.6999999999999999e+307, bRecord=true, bApi=false)
    at /home/julien/compile-libreoffice/libo/sc/source/ui/docshell/docfunc.cxx:4450

and ScTable::GetEmptyLinesInBlock returns 5 (instead of expected value 6).
Then I unwinded from there.
   1235         case DIR_BOTTOM:
   1236         {
   1237             // Determine the length empty tail segment.
   1238             size_t nLength = nEndRow - nStartRow + 1;
   1239             std::pair<sc::CellStoreType::const_iterator,size_t> aPos = maCells.position(nEndRow);
   1240             sc::CellStoreType::const_iterator it = aPos.first;
   1241             if (it->type != sc::element_type_empty)
   1242                 // end row is already not empty.
   1243                 return 0;
   1244 
   1245             // length of this empty block from the tip to the end row position.
   1246             size_t nThisLen = aPos.second;
   1247             return std::min(nThisLen, nLength);
   1248         }
nLength = 6 but nThisLen = 5 which brought me there:
workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_def.inl
   1231 template<typename _CellBlockFunc>
   1232 typename multi_type_vector<_CellBlockFunc>::const_position_type
   1233 multi_type_vector<_CellBlockFunc>::position(size_type pos) const
   1234 {
   1235     size_type start_row = 0;
   1236     size_type block_index = 0;
   1237     if (!get_block_position(pos, start_row, block_index))
   1238         throw std::out_of_range("Block position not found!");
   1239 
   1240     typename blocks_type::const_iterator block_pos = m_blocks.begin();
   1241     std::advance(block_pos, block_index);
   1242     const_iterator it = const_iterator(block_pos, m_blocks.end(), start_row, block_index);
   1243     return const_position_type(it, pos - start_row);
   1244 }
start_row = 1 (instead of 0).
which finally brought me here:
    551 template<typename _CellBlockFunc>
    552 bool multi_type_vector<_CellBlockFunc>::get_block_position(
    553     size_type row, size_type& start_row, size_type& block_index) const
    554 {
    555     for (size_type i = block_index, n = m_blocks.size(); i < n; ++i)
    556     {
    557         const block& blk = *m_blocks[i];
    558         if (row < start_row + blk.m_size)
    559         {
    560             // Row is in this block.
    561             block_index = i;
    562             return true;
    563         }
    564 
    565         // Specified row is not in this block.
    566         start_row += blk.m_size;
    567     }
    568 
    569     return false;
    570 }
We don't go line 562 at the first time so start_row is incremented.
Now I'm quite stuck because I don't know how blocks work.

Kohei/Eike/Markus: any idea?
Comment 8 Kohei Yoshida 2014-03-07 18:24:04 UTC
I'll take this.
Comment 9 Commit Notification 2014-03-07 19:26:45 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9d54a7f67196cac2a5701c06d8dc55f102d0af60

fdo#75718: Write unit test for this.



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2014-03-07 19:26:59 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=01de94471c20a8b9c36d6080638d70e57eac55bf

fdo#75718: Correctly count the length of trailing empty range.



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 11 Kohei Yoshida 2014-03-07 19:28:27 UTC
4.2 backport: https://gerrit.libreoffice.org/8501
Comment 12 Commit Notification 2014-03-07 22:37:38 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=92a2cb1bc23d9b0e099f34bcd4c2b89d3682ce60&h=libreoffice-4-2

fdo#75718: Correctly count the length of trailing empty range.


It will be available in LibreOffice 4.2.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 Kohei Yoshida 2014-03-07 23:07:48 UTC
Fixed.
Comment 14 Julien Nabet 2014-03-08 09:58:51 UTC
Checked on master sources updated today, thank you Kohei!