Created attachment 69603 [details] ods-file with content in two hidden rows Hello! The Windows version of LibreOffice Calc contains the following error (Linux and Mac versions were not tested): The content of hidden cells is not copied when a row or column is selected and dragged. Example: 1. Open the attached Calc-file (dragging_error_in_hidden_rows.ods). 2. Select cells D1:D5 and drag them 3 or 4 columns to the right. 3. Make hidden rows 2 and 4 visible. 4. The content of the visible rows 1, 3 and 5 is copied. The content of the hidden rows 2 and 4 is missing. This is an 3.6.x issue. LibreOffice Calc up to version 3.5.5 did this operation correctly. Best regards, Mark
not reproducible with LO 4.0.1.2 (Win7 Home, 64bit) I suppose that this issue has been resolved. @Mark: Can you also confirm that you did not experience this anymore with the latest release of LO?
Created attachment 76608 [details] dragging_error_in_hidden_rows (rev).ods I am sorry to say that I cannot confirm the resolution of this issue. There was no problem up to LO 3.5.5. It started with LO 3.6 and lasts until LO 4.0.1.2 (Win 7, 64 bit). Please try the attached, improved spreadsheet. There is not supposed to be any divison by zero by just selecting cells d1:d5 and dragging this column to the right. By the way, MS Excel does not show this behavior. Best regards, Mark Gesendet: Samstag, 16. März 2013 um 12:17 Uhr Von: bugzilla-daemon@freedesktop.org An: mark.ebner@gmx.net Betreff: [Bug 56799] LibreOffice Calc: Missing content by dragging hidden rows and columns Comment # 1[https://bugs.freedesktop.org/show_bug.cgi?id=56799#c1] on bug 56799[https://bugs.freedesktop.org/show_bug.cgi?id=56799] from A[stgohi-lobugs@yahoo.de] not reproducible with LO 4.0.1.2 (Win7 Home, 64bit) I suppose that this issue has been resolved. @Mark: Can you also confirm that you did not experience this anymore with the latest release of LO? ------------------------------------------------------------ You are receiving this mail because: You reported the bug.
seemed to be strange, I still can't reproduce it, everything is fine with LO 4.0.1.2 (Win7 Home, 64bit), I tried it several times Can anybody else confirm this behavior?
Checked with: LO 4.0.2.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Could not reproduce. ods-file with content in two hidden rows Selected D1:D5, dragged to H, D2 and D4 are visible - both have value of 3. dragging_error_in_hidden_rows (rev).ods Selected D1:D5, dragged to H, D2 and D4 are visible - both have value of 0,3333333333.
I see nothing wrong on both files attached. Tested with LO 4.0.3.3 (Win7 Home Premium 32bit) @Mark, have you test it with LO 4.0.3? Using standard installation & setting? This problem always happen or rarely?
Created attachment 79342 [details] LO 4.0.3 after dragging to the right.jpg I use two PCs: - At home: Windows 7 (64 bit) with LibreOffice 4.0.3 (standard version) - Business: Windows 7 (32 bit) with LibreOffice 4.0.3 (portable version) The problem can be reproduced on both PCs and all LibreOffice versions since 3.6. I can also go back to LibreOffice 3.5.5 and the issue is solved again. Attached are three screen shots: - LO x.y.z before dragging cells D1:D6 to the right - LO 4.0.3 after dragging cells D1:D6 to the right - LO 3.5.5 after dragging cells D1:D6 to the right
Created attachment 79343 [details] LO x.y.z before dragging to the right.gif
Created attachment 79344 [details] LO 3.5.5 after dragging to the right.gif
Confirmed with: LO 4.0.2.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit dragging_error_in_hidden_rows (rev).ods: Hidden rows - #DIV/0! in E2, E4 Visible rows - 0,25 in E2, E4 Screenshots cleared things out for me - seems I misunderstood this report a little bit. Now I see that by dragging you wanted to fill cells to the right using fill handle and not select and move cells as I thought.
Ok I understand & confirm that bug reproducible with LO 4.0.3.3 (Win7 32bit) Formula in hidden cell can't be copied Set status to UNCONFIRMED -> maybe need 1 more confirmation?
Created attachment 79456 [details] Blank cells in LO Version 4.0.3.3 Confirmed with: LO Version 4.0.3.3 (Build ID: 400m0(Build:3)) Debian Sid 2013-05-17 For me the cells are blank instead of #DIV/0!
Scratch what I said about #DIV/0! I overlooked the second attachment & misread some comments. For "dragging_error_in_hidden_rows (rev).ods", dragging with rows hidden: E1: 4 E2: E3: #DIV/0! E4: E5: #DIV/0! And dragging with rows visible: E1: 4 E2: 0.25 E3: 4 E4: 0.25 E5: 4 Confirmed.
Bug still present in 4.0.4.2. For those who are a heavy user of the drag-extend feature like me, here's the workaround I'm using to circumvent this issue while it's not fixed: instead of hiding the rows/columns, just set their height/width to a small value like 0.01cm. This won't make the R/C truly "hidden" in the sense that will prevent LO from drag-extending their contents, but for most practical purposes, the R/C will be out of sight.
With attached file from comment 2, still reproduced with LO 4.3.1.1 and 4.2.6.2 under Ubuntu 12.04 x86. Dragging/fill handle with LO 3.5.7.2 works as expected as shown in comment 8
9236fd0352a4a587faac6f15f6b3b5331301380f is the first bad commit commit 9236fd0352a4a587faac6f15f6b3b5331301380f Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed May 2 19:13:38 2012 +0200 source-hash-250feedd8e50e5eb52682a194823567ba5287c60 commit 250feedd8e50e5eb52682a194823567ba5287c60 Author: Petr Mladek <pmladek@suse.cz> AuthorDate: Wed Apr 11 18:00:10 2012 +0200 Commit: Petr Mladek <pmladek@suse.cz> CommitDate: Thu Apr 12 13:31:58 2012 +0200 add scalable desktop icons (fdo#39690) :100644 100644 cc40725717656158f0039a1fd8fd10fb746f8643 c9b2f7dcd2779139e9e6592d58cf443fe49ee0a6 M ccache.log :100644 100644 c42b86936bb1a136b07fd1142367179a698d2dec 2e77f59aa1eaa7e38da030ecd18a327187243965 M commitmsg :100644 100644 d4272c5ec9f0958da797b4ae75ac84c9d87d9a14 436794c66d503d7d0e2db756cb46ca58e766c129 M dev-install.log :100644 100644 22b4eaf6e467bc43e98b4eec578c69a0a8ef6bce 0ef1bcf705ecebe183817b59275bfc7f24de11a8 M make.log :040000 040000 29d0e07acf7cdb2eeae63ed25bae0ea214759321 67e69a46d840fe1a91f3f4f02c9ff5bef5c0dc89 M opt :100644 100644 2879fe75d9469dc9351126270662e7fc489b7998 46dac5fee1d942ebd088dab1d4c4ffc4dbba4cb4 M patch.log git bisect log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327 # good: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 git bisect good 369369915d3582924b3d01c9b01167268ed38f3b # bad: [6fce03a944bf50e90cd31e2d559fe8705ccc993e] source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7 git bisect bad 6fce03a944bf50e90cd31e2d559fe8705ccc993e # bad: [8a39227e344637eb7154a10ac825d211e64d584c] source-hash-f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf git bisect bad 8a39227e344637eb7154a10ac825d211e64d584c # bad: [e8bc60acad752e284db73fc4d8ad383ac055361c] source-hash-7e6e16ba6de2d3ef2b130d1ad5ffeabfdb37918e git bisect bad e8bc60acad752e284db73fc4d8ad383ac055361c # good: [19b8950109d519c0dba847f94d5d166044c1db15] source-hash-ff9cca69744b54ca84d98476a9a969d1aa0ff2d3 git bisect good 19b8950109d519c0dba847f94d5d166044c1db15 # bad: [c65ac52362b5c5286abebd55d9ba9a8169e0a6aa] source-hash-ad50ae4f3c48a82315f70fff1b9f221e5c74a2da git bisect bad c65ac52362b5c5286abebd55d9ba9a8169e0a6aa # bad: [9236fd0352a4a587faac6f15f6b3b5331301380f] source-hash-250feedd8e50e5eb52682a194823567ba5287c60 git bisect bad 9236fd0352a4a587faac6f15f6b3b5331301380f # good: [001b8be798d9875b6f699c573f4147d04caece67] source-hash-ee7084c4f720c932df67c8ff033dab4d8d556179 git bisect good 001b8be798d9875b6f699c573f4147d04caece67 # first bad commit: [9236fd0352a4a587faac6f15f6b3b5331301380f] source-hash-250feedd8e50e5eb52682a194823567ba5287c60
I can't reproduce the bug with LOO 4.2.6.3 on Linux Ubuntu 14.04. Is there the same problem as https://bugs.freedesktop.org/show_bug.cgi?id=85170 ?
*** Bug 94492 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
Problem still exists. Version: 5.2.4.2 Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0
Actually this was a deliberate change and not a regression. Hidden rows and columns are ignored where ever we touch some code that does not do it yet. There are just too many issues that users had with accidentally overwritten content.
*** Bug 137774 has been marked as a duplicate of this bug. ***