Bug 92650 - Editing : Formula not updating on undo.
Summary: Editing : Formula not updating on undo.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.4.4.2 rc
Hardware: All All
: medium normal
Assignee: Kohei Yoshida
QA Contact:
URL:
Whiteboard: target:5.4.0 target:5.3.3 target:5.2....
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2015-07-09 09:38 UTC by Jaise James
Modified: 2017-04-25 13:19 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Problem file (9.60 KB, application/vnd.oasis.opendocument.spreadsheet)
2015-07-09 09:38 UTC, Jaise James
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaise James 2015-07-09 09:38:45 UTC
Created attachment 117154 [details]
Problem file

please see the attached file

Step to reproduce 

1. check the formula in red cell.

2. Drag & Drop the grey cells on to yellow cells

3. Undo operation

4. Check the formula in red cell. 

Formula is not restored to first one.
Comment 1 Terrence Enger 2015-07-09 20:07:42 UTC
To clarify what I see happening:
(*) The drag operation changes the formula and the value in cell B5.
    The formula in cell B8 references B5, and the value is correctly
    recalculated.
(*) The undo operation adjusts the formula in cell B8 to reference B3
    instead of B5.
Funnily enough, that adjustment of the formula in B8 would be correct
if the user, instead of "undo", dragged cells A5 and B5 back to row 3.

But my expectation is that "undo" should set things back to the way
they started.  Hence I am setting status NEW.

I see the bug in daily debug bibisect repository version 2015-07-19
and on Windows Vista with LibreOffice ...

    Version: 5.1.0.0.alpha1+
    Build ID: d3b6f3790953bdfeaeebcd3ba9ec370d94ca4ebf
    TinderBox: Win-x86@39, Branch:master, Time: 2015-07-09_00:11:56
    Locale: en-CA (en_CA)

but my clarification is based on the first "bad" commit, source-hash
3c4fb52.


I am setting keyword regression and whiteboard bibisected because I
see from `git bisect good` ...

    a17c4dfec4394f179947caebc419a9b3dade8c1d is the first bad commit
    commit a17c4dfec4394f179947caebc419a9b3dade8c1d
    Author: Matthew Francis <mjay.francis@gmail.com>
    Date:   Thu May 28 21:36:07 2015 +0800

        source-hash-3c4fb52d8fc89fe43983991ed2339295b2e0ef8c
    
        commit 3c4fb52d8fc89fe43983991ed2339295b2e0ef8c
        Author:     Kohei Yoshida <kohei.yoshida@collabora.com>
        AuthorDate: Thu May 1 01:15:02 2014 -0400
        Commit:     Kohei Yoshida <kohei.yoshida@collabora.com>
        CommitDate: Thu May 1 01:18:50 2014 -0400
    
            fdo#78079: Re-work sort by column to get it to do the right thing.
    
            Also fixed reference update problem.
    
            Change-Id: I06e6115ef969a011fdd5c92d5eb1927fb7ae789b

    :040000 040000 d833fb741290f5be266434f8f220ec8cbc3ff9de 8bb8e139223247084ab4dcd44f20a0d22c3e6945 M	opt

and from `git bisect log` ...

    # bad: [74b89c3193673ba9897dc4a4541500ef6e8d9bf7] source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64
    # good: [9c392cfdfe6e9a9bce98555ea989283a957aa3ad] source-hash-fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3
    git bisect start 'latest' 'oldest'
    # good: [e289d9d328719fd70e9a2680fd0e4f586a97b3be] source-hash-3c0a7cf4f67720f2cca2c4eb543f838d5b644e7f
    git bisect good e289d9d328719fd70e9a2680fd0e4f586a97b3be
    # good: [3e807472869ed7d72b026c12cd1e7c3cb990591f] source-hash-6390dd9777ff63ca75a088e56dd444a355439343
    git bisect good 3e807472869ed7d72b026c12cd1e7c3cb990591f
    # good: [badf3854a52f4805b58cb5d82c7f5008bb08d70e] source-hash-a911f866623db7a03b12f0143df8d54a95805581
    git bisect good badf3854a52f4805b58cb5d82c7f5008bb08d70e
    # bad: [f68a3ffd75febb1be3f68d578bba9d65d43317e6] source-hash-34509a0805d408cd45c1b95f5afdafdc46c1501e
    git bisect bad f68a3ffd75febb1be3f68d578bba9d65d43317e6
    # skip: [8be4243e79ee878acbe44bdeaeea28db91b29695] source-hash-d3832fc4e030c29eb9b7aef43931c46c66db3bc8
    git bisect skip 8be4243e79ee878acbe44bdeaeea28db91b29695
    # skip: [248b8919558872c64534b2965f067634ce10eb15] source-hash-4b6ba1eae6c2bae982190618ed46e9b66a3b2b2a
    git bisect skip 248b8919558872c64534b2965f067634ce10eb15
    # bad: [e37190ac16bf913cc7ec57882be6823c9b1476eb] source-hash-3f569908ac72c20826a45ebed59af9b1e5449207
    git bisect bad e37190ac16bf913cc7ec57882be6823c9b1476eb
    # good: [1c013f3898c97b12c367d29eb1f86fab7fac45cd] source-hash-1e5b495a882493a81cc82ee34e3339b071bc162d
    git bisect good 1c013f3898c97b12c367d29eb1f86fab7fac45cd
    # bad: [0fab4e2ef82937c4f9f10b06cc4e67dbf895d189] source-hash-cedbbe2f78a6a07d79b43d71f36738b46cf62c38
    git bisect bad 0fab4e2ef82937c4f9f10b06cc4e67dbf895d189
    # good: [2cf4c9ea96cd5c47211c531037f3d295d6827209] source-hash-62f6bb72f00e30427e29b499c24432f5f980fa9f
    git bisect good 2cf4c9ea96cd5c47211c531037f3d295d6827209
    # good: [cae27718f3e58af4d369f4dbc6b92f74811e9aa9] source-hash-2dda1cd4d1927790d546dbaf1893279d18515bae
    git bisect good cae27718f3e58af4d369f4dbc6b92f74811e9aa9
    # good: [0f1d8c9756179b825f05c8031f8752ef2e2564b9] source-hash-9a1196aae48162a456c7c56bf703a89972ade9b2
    git bisect good 0f1d8c9756179b825f05c8031f8752ef2e2564b9
    # bad: [09270440c77d2a7d968dd0da2ea5bd3e05a909f1] source-hash-f2e4bb4b96a7c2176a0dd1dacd9930bf9b68d895
    git bisect bad 09270440c77d2a7d968dd0da2ea5bd3e05a909f1
    # bad: [7f9eba478e3e78db625397359a9e3734fac32c86] source-hash-aa668984f6a1f6e5c4d3d23dc89bab59f66baa5c
    git bisect bad 7f9eba478e3e78db625397359a9e3734fac32c86
    # bad: [a17c4dfec4394f179947caebc419a9b3dade8c1d] source-hash-3c4fb52d8fc89fe43983991ed2339295b2e0ef8c
    git bisect bad a17c4dfec4394f179947caebc419a9b3dade8c1d
    # good: [cfceb245762a5dc4f3d3dd843184fae98742988b] source-hash-0e443b773454fa153827753812757d88eea932c5
    git bisect good cfceb245762a5dc4f3d3dd843184fae98742988b
    # first bad commit: [a17c4dfec4394f179947caebc419a9b3dade8c1d] source-hash-3c4fb52d8fc89fe43983991ed2339295b2e0ef8c
Comment 2 Robinson Tryon (qubit) 2015-12-13 11:13:23 UTC Comment hidden (obsolete)
Comment 3 Xisco Faulí 2016-10-03 09:24:13 UTC
Adding Cc: to Kohei Yoshida
Comment 4 Eike Rathke 2016-10-11 15:41:32 UTC
The commit mentioned in comment 1 may be related in that it manifests the bug, but the changes in ScUndoDragDrop that eliminated the use of ScRefUndoData since commit 27182231acd3a0c9898a8dba78b76dc8a827b4c0 seem to be the original cause. This scenario (data moved into an existing reference) probably can not be undone without a reference undo doc.

I'm trying to take a stab at this.
Comment 5 Kohei Yoshida 2017-03-25 01:22:55 UTC
@Eike: It's been 5 months since you grabbed this, so I assume you've pushed this aside for the time being.

Let me take a look into this since this is technically my regression.
Comment 6 Commit Notification 2017-04-13 02:41:34 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d588e65021ad3d00a91a2732b2a6cf4c59b3534

tdf#92650: handle overwritten references correctly in undo.

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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 7 Commit Notification 2017-04-13 02:42:09 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a572975704a0d01e458191e8d66ff20ef60e4a8

tdf#92650: add a unit test for this.

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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Kohei Yoshida 2017-04-14 14:55:40 UTC
Backport in progress:
5.3: https://gerrit.libreoffice.org/36539
5.2: https://gerrit.libreoffice.org/36540
Comment 9 Terrence Enger 2017-04-14 22:19:44 UTC
Thank you, Kohei.  I see the fix in daily Linux dbgutil bibisect repository version 2017-04-14.

I shall leave it for Jaise to set status VERIFIED FIXED.
Comment 10 Commit Notification 2017-04-18 20:06:44 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=856a2d868fedd010d58d6082d3cb4753a019408a&h=libreoffice-5-3

tdf#92650: handle overwritten references correctly in undo.

It will be available in 5.3.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 11 Commit Notification 2017-04-18 20:11:46 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7f5614209ffa2eef2e78bdb976d30d2f5b7fff48&h=libreoffice-5-2

tdf#92650: handle overwritten references correctly in undo.

It will be available in 5.2.8.

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 12 Kohei Yoshida 2017-04-18 20:57:30 UTC
(In reply to Terrence Enger from comment #9)
> Thank you, Kohei.  I see the fix in daily Linux dbgutil bibisect repository
> version 2017-04-14.
> 
> I shall leave it for Jaise to set status VERIFIED FIXED.

Well, I think having you verify it should be sufficient.  I'll mark it fixed.
Comment 13 Commit Notification 2017-04-25 13:19:45 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "libreoffice-5-2-7":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7e2ee5ad4aca628b2bfa90b20154f42f42bfe6ba&h=libreoffice-5-2-7

tdf#92650: handle overwritten references correctly in undo.

It will be available in 5.2.7.

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.