Created attachment 63149 [details] Selected (filtered) datasource content is pasted in A1 resulting in a duplicated last row (shown by selected cells) Problem description: Data which is copied from a filtered data source adds a duplicate of the last row when pasted into a spreadsheet. Steps to reproduce: 1. Press F4 to open datasources 2. Select a data source and let it display the data in the datasource window 3. Click on Autofilter to filter out only some data 4. Click on the top left (empty) square in the data source view to select all the filtered data 5. Ctrl-C to copy 6. Select a cell in the spreadsheet 7. Ctrl-V to paste Current behavior: The last row is duplicated Expected behavior: The last row should not be duplicated Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
Confirmed with: LO 4.0.0.1 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit It is even worse. I tried on biblio database. Filtered "Gris, Myriam" entry (5 found). After copy and paste last entry ("GRM04 1 Gris, Myriam") was duplicated 379 times. Total data rows with header, filtered and duplicated entries = 385 rows. There are 384 records in biblio database. 384 plus header = 385. Coincidence?
While working with the other bug I noticed that biblio database has 20 records. I repeated the steps from comment 1 few times in a row (in the same or new Calc session) and found out that I got mixed results every time. One time it is copying fine, other the counter for total records is increased every time you click Copy over the empty button (that is how I got over 300 records) and when you select copy last row is duplicated x times, just to match new total records count. Few times Calc just crashed while pasting. This bug, it seems, needs some more testing...
Bug confirmed in version 4.1.0.2. I get the same effects by using a registered data source (in my case it is a MySQL Database hosted on a net-share, connected via Base and ODBC). I have defined different queries, and by importing the results via datasource explorer (F4 - select query) and drag&drop all data to a calc sheet, last row will be duplicated. See attached picture (query-import_to_calc_sheet.png). Bug changed to critical. It is an unexpected behavior and in business-applications nobody will check all imported rows, if they are doubled. So behaviour may generate wrong results in calculations!
Created attachment 82281 [details] result of drag&drop action query results
Hi Lionel, should this be an MAB do you think ? is it a regression ?
(In reply to comment #5) > should this be an MAB do you think ? I think it is "very annoying". > is it a regression ? Thomas filled in "3.5" as version; if that is correct, then it is a quite old bug. Don't have definite information on whether it is a regression compared to 3.4, 3.3, or OpenOffice.org. I don't get it with all databases (and in particular not with the bibliography database); it seems to be linked to the absence of primary key in the table. In a dbgutil build, I get during the *copy* action (not paste) about as many warn:legacy.osl:25490:1:svx/source/fmcomp/fmgridcl.cxx:1883: FmGridControl::DeleteSelectedRows : a bookmark could not be determined ! on stderr than there are duplicates. This looks like a clue to follow. This OSL_FAIL is actually in FmGridControl::getSelectionBookmarks, not FmGridControl::DeleteSelectedRows, and I see: i == about number of records in filter/selection nSelectedRows == about number of records in table, but should be number of records in selection This wrong value of nSelectedRows is probably the cause. WIll investigate further.
The selection is made by BrowseBox::SelectAll which select "all" based on the number of rows UNfiltered, via rRow.pSel->SelectAll. OTOH, GetRowCount() returns the FILTERED amount of rows, so probably we need to update rRow.pSel at the same time as nRowCount when the filter is applied. Will try to look into it another day.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6036ae611e3667a07d7239857e2d6955f7292810 fdo#51180 reset (Multi)Selection on Clear() 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.
Backport to 4.1 and 4.2 requested at gerrit and pending.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=554710d39029b1ddf244d55fc6b464a8a896ea6a&h=libreoffice-4-2 fdo#51180 reset (Multi)Selection on Clear() It will be available in LibreOffice 4.2.1. 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.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=873be8f3ff28fd06b531b17d2c7cc41cbc1385e8&h=libreoffice-4-1 fdo#51180 reset (Multi)Selection on Clear() It will be available in LibreOffice 4.1.6. 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.