Bug 56799 - Missing content by dragging / fill handle hidden rows and columns
Summary: Missing content by dragging / fill handle hidden rows and columns
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Spreadsheet (show other bugs)
Version: 3.6.0.4 release
Hardware: All All
: high normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: bibisected
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-11-06 09:50 UTC by Mark
Modified: 2014-10-18 17:14 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments
ods-file with content in two hidden rows (8.04 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-11-06 09:50 UTC, Mark
Details
dragging_error_in_hidden_rows (rev).ods (8.07 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-03-16 14:13 UTC, Mark
Details
LO 4.0.3 after dragging to the right.jpg (81.00 KB, image/jpeg)
2013-05-15 12:16 UTC, Mark
Details
LO x.y.z before dragging to the right.gif (148.58 KB, image/gif)
2013-05-15 12:16 UTC, Mark
Details
LO 3.5.5 after dragging to the right.gif (183.39 KB, image/gif)
2013-05-15 12:16 UTC, Mark
Details
Blank cells in LO Version 4.0.3.3 (68.78 KB, image/png)
2013-05-17 08:39 UTC, Ted Wulf
Details

Description Mark 2012-11-06 09:50:33 UTC
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
Comment 1 A (Andy) 2013-03-16 11:17:29 UTC
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?
Comment 2 Mark 2013-03-16 14:13:06 UTC
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.
Comment 3 A (Andy) 2013-03-29 16:18:54 UTC
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?
Comment 4 bfoman 2013-05-13 12:59:36 UTC
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.
Comment 5 ign_christian 2013-05-15 09:02:05 UTC
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?
Comment 6 Mark 2013-05-15 12:16:42 UTC
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
Comment 7 Mark 2013-05-15 12:16:42 UTC
Created attachment 79343 [details]
LO x.y.z before dragging to the right.gif
Comment 8 Mark 2013-05-15 12:16:42 UTC
Created attachment 79344 [details]
LO 3.5.5 after dragging to the right.gif
Comment 9 bfoman 2013-05-16 09:15:30 UTC
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.
Comment 10 ign_christian 2013-05-16 10:39:20 UTC
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?
Comment 11 Ted Wulf 2013-05-17 08:39:25 UTC
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!
Comment 12 Ted Wulf 2013-05-17 08:59:46 UTC
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.
Comment 13 Flávio Veloso 2013-06-26 02:33:53 UTC
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.
Comment 14 ign_christian 2014-08-22 10:06:11 UTC
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
Comment 15 raal 2014-08-31 19:02:06 UTC
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
Comment 16 Migrec 2014-10-18 17:14:24 UTC
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 ?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.