Bug 63593 - New edited cell gets moved when creating new Sheet
Summary: New edited cell gets moved when creating new Sheet
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Mike Kaganski
Whiteboard: target:5.4.0
Keywords: bibisected, bisected, regression
: 86673 91630 100430 (view as bug list)
Depends on:
Reported: 2013-04-16 09:14 UTC by Tudor Simion
Modified: 2017-03-01 16:28 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Tudor Simion 2013-04-16 09:14:34 UTC
Replication Steps:
1) Open LibreOffice Calc.
2) Go to a new cell and write some text. Do not click outside the cell. Keep the editing line inside the cell.
3) With the mouse, press the "new sheet" button on the bottom left corner.

Expected behavior:
a) A new blank sheet is created
b) The action is not possible (Microsoft Excel behavior). It is blocked until we click outside the edited cell.

Actual Behavior:
The blank sheet contains the new edited cell and the old sheet is empty.
Comment 1 Marc Kaulisch 2013-04-16 20:15:09 UTC
I can confirm this behaviour (with LO in Windows 8). It is not intuitive but does not seem to be a bug either because no information is lost.
Comment 2 Marc Kaulisch 2014-06-27 11:03:03 UTC
I do not know if this is fixed but I cannot reproduce this bug anymore in LO
Text remains in the old sheet
Comment 3 Marc Kaulisch 2014-08-11 11:43:04 UTC
either my report from 27th June was incorrect or something has changed. The behaviour described in the bug report is still/again present in
Comment 4 ign_christian 2014-08-11 13:25:38 UTC
Confirm reproduced with,, - Ubuntu 12.04 x86

LO seems behave as expected, new empty sheet created & edited cell in old sheet still exist.

I also don't know whether it's a bug or by design. Setting NEW temporarily
Comment 5 raal 2014-11-25 10:09:07 UTC
*** Bug 86673 has been marked as a duplicate of this bug. ***
Comment 6 raal 2015-03-07 08:56:29 UTC
 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
# bad: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4
git bisect bad 369369915d3582924b3d01c9b01167268ed38f3b
# bad: [351622aec2dff3cc3bbbb020ad0097c4322d2a21] source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c
git bisect bad 351622aec2dff3cc3bbbb020ad0097c4322d2a21
# good: [035c276ec5a8da669e6043a3db6b0701dd3c2ade] source-hash-dc8249af103741415a074d9bbf8b1211f24a7c3f
git bisect good 035c276ec5a8da669e6043a3db6b0701dd3c2ade
# bad: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4
git bisect bad d1cca78ab77d64482b6643bc643d29dbe2dd1442
# bad: [bd61690e049a1941a9a555c391165d4cf7288e3b] source-hash-1ca547d20882e9b3d3ba9a6c7ee0340a5b7009b0
git bisect bad bd61690e049a1941a9a555c391165d4cf7288e3b
# good: [522a31bbab6f0abeca2e5bcf565c399850746298] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3
git bisect good 522a31bbab6f0abeca2e5bcf565c399850746298
# bad: [edfa0e7d756a6bd772cd39f890e5308251fe72f5] source-hash-6598e65cfcabd270199d09d11d9d93639bca620d
git bisect bad edfa0e7d756a6bd772cd39f890e5308251fe72f5
# bad: [1a972e6e9fb1e5c730658348e2231151310c09f9] source-hash-c5e280b4144d3ed642404079f464a42829be3f80
git bisect bad 1a972e6e9fb1e5c730658348e2231151310c09f9
# first bad commit: [1a972e6e9fb1e5c730658348e2231151310c09f9] source-hash-c5e280b4144d3ed642404079f464a42829be3f80

Comment 7 raal 2015-05-26 08:09:34 UTC
*** Bug 91630 has been marked as a duplicate of this bug. ***
Comment 8 Robinson Tryon (qubit) 2015-12-13 11:09:28 UTC Comment hidden (obsolete)
Comment 9 Buovjaga 2016-06-18 19:29:27 UTC
*** Bug 100430 has been marked as a duplicate of this bug. ***
Comment 10 Mike Kaganski 2016-12-09 13:15:19 UTC
The problem is fixed in current master by reverting the following single commit (thanks raal for bibisection!):

author	Markus Mohrhard <markus.mohrhard@googlemail.com>	2011-10-31 20:38:44 (GMT)
committer	Markus Mohrhard <markus.mohrhard@googlemail.com>	2011-10-31 20:40:59 (GMT)
commit 88f91adf266f19659014df22e09ce6c6761fb6f1
tree d6082d5b2036011ebf226849263f408afb115ce5
parent 0ca429a00b6fca4eed328d106e95b447dd813e58
update first ScMarkData before setting cursor (fdo#42432)

The revert looks like a proper fix, because it does not reintroduce Bug 42432. Seems that something had changed since then.

However, I am adding Markus so that he could just confirm if reverting that is OK.
Comment 11 Mike Kaganski 2016-12-10 21:42:41 UTC
A patch is on review: https://gerrit.libreoffice.org/31843
Comment 12 Commit Notification 2016-12-12 03:33:54 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":


tdf#63593: revert 88f91adf266f19659014df22e09ce6c6761fb6f1

It will be available in 5.4.0.

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:

Affected users are encouraged to test the fix and report feedback.
Comment 13 Xisco Faulí 2017-03-01 11:12:47 UTC
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Comment 14 Mike Kaganski 2017-03-01 16:28:22 UTC
I waited for OP to check, but as there's no feedback, closing it as fixed.