Created attachment 118075 [details] Numbers from formula still appear. I deleted the contents of some cell (cannot remember the range, I think it must have being A2:W34). I expected to see all numbers disappears, but in cells I32, L32 and V32, the old result from the formula still is visible. How can that be? Bug? As far I know, all cells that the formula refers to are empty.
Hi Grobe - Unfortunately this bug report is not valid. There are no clear steps to reproduce and you said that you can't even remember what content you deleted. For what it's worth - I selected A2:W34 on sheet Kvartal_1, deleted the content, and it all deleted without a problem. I am setting this to NEEDINFO - if you can reproduce the issue and provide clear reproducible steps set to UNCONFIRMED. Else this bug will be closed as INVALID in 7 months. Thanks
Created attachment 118087 [details] Libre Office document I've tested this some more. fortunately I found an older copy (backup) of the same document BEFORE removing the cell contents. I'll upload a copy of this document (stripped away some sheets). Aditionally I've made a short video clip showing the steps to reproduce.
Created attachment 118088 [details] Video clip describe bug Video clip show steps to reproduce
New file attached (previous post). I came to think that I might as well write down the steps to reproduce: * Open the document (https://bugs.documentfoundation.org/attachment.cgi?id=118087) * Make sure the sheet named "Kvittering" is the active one. * Select range A2:D6 * Press Delete backwards button (or Edit --> Delete contents) * Uncheck "Formulas" checkbox. * hit ok button. Expect to see: All contents gone, should be no visible contents in any of the cells in range A2:D6. What I actually got: Previous result in cell D6 still remains visible (number -81).
@Grobe - great instructions :) Thanks Confirmed Ubuntu 15.04 x64 LibreOffice 4.4.5.2, 5.0.0.5 (both confirmed) LibreOffice 3.3 seems okay New; Minor - can slow down professional quality work but won't prevent it; High - an error can slip through on a more complicated file that a user would not reasonably see without quite a bit of inspection of the file @Grobe - if you have some time to help out - QA would love to see you in the chat http://webchat.freenode.net/?channels=libreoffice-qa
I have bibisected this bug. The behaviour changed in the range of the "lo-linux-dbgutil-daily" bibisect repository (though I had expected it sooner according to comment 5; maybe the respective commit has been backported to LibreOffice 4.4 as it seems to be present in version 4.4.5.2). 43d971d013fc757bfbe0fdec122ed1a9a693bd47 is the first bad commit commit 43d971d013fc757bfbe0fdec122ed1a9a693bd47 Author: Miklos Vajna <vmiklos@collabora.co.uk> Date: Wed Jul 8 04:47:17 2015 +0200 2015-07-08: source-hash-ff669d1c7f692052534d1136d1ff4220433f8542 :100644 100644 4f0357bce19802b8714a10e25482be00144e3210 eec062d0a886ebc30324db6809bbe2b26251616c M build-info.txt :040000 040000 d201531589b6310dc15010565167145134cde463 54f63208743b2615b8106ac47ca9840016362802 M opt $ git bisect log # bad: [9a14314f1a4144b1b61d14e5454eab556a7b0201] 2015-08-24: source-hash-b103e7d786f5b7ec6cfe4f53f2ca317f06ceabc5 # good: [2b392af9c8f54629e3a3a98a8c92fa5af1c6722f] 2015-05-20: source-hash-90e2dabb8d0bb5382234be776c2ad0e2d5d9e224 git bisect start '9a14314f1a4144b1b61d14e5454eab556a7b0201' '2b392af9c8f54629e3a3a98a8c92fa5af1c6722f' # good: [136b8f86a09839b55e7c25e4cf82e439c496f3ce] 2015-07-07: source-hash-0251e61640b94094918406b33ee7b05564409feb git bisect good 136b8f86a09839b55e7c25e4cf82e439c496f3ce # bad: [f7a251c888dced052c1b7698596d05c39c1775dc] 2015-07-31: source-hash-2d9db406d301d722649ca539cacad823b89191ca git bisect bad f7a251c888dced052c1b7698596d05c39c1775dc # bad: [9f53d6035f583ef371ac2799768bf5fd22e10892] 2015-07-19: source-hash-c2c51fa587523edd6e31a17affffc77645b60dea git bisect bad 9f53d6035f583ef371ac2799768bf5fd22e10892 # bad: [f786cc13dd437ac161a7aea04c2016e4a4c6a459] 2015-07-13: source-hash-7f0161d88e3a496361e2209d31cc7e9ef42a677e git bisect bad f786cc13dd437ac161a7aea04c2016e4a4c6a459 # bad: [1b45cefc5217a763278907368a3f27d761e2e1ff] 2015-07-10: source-hash-83b53164b096b4cba94a2e1ee8b620228bee8a3a git bisect bad 1b45cefc5217a763278907368a3f27d761e2e1ff # bad: [02f749eef951ff74ff6184cd0c5c13cc6e97f915] 2015-07-09: source-hash-85ce6a2446deb0f4c01604b6188f969603de9b16 git bisect bad 02f749eef951ff74ff6184cd0c5c13cc6e97f915 # bad: [43d971d013fc757bfbe0fdec122ed1a9a693bd47] 2015-07-08: source-hash-ff669d1c7f692052534d1136d1ff4220433f8542 git bisect bad 43d971d013fc757bfbe0fdec122ed1a9a693bd47 # first bad commit: [43d971d013fc757bfbe0fdec122ed1a9a693bd47] 2015-07-08: source-hash-ff669d1c7f692052534d1136d1ff4220433f8542
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Seems to be fixed in recent releases of both fresh and still versions (like 5.1.4.2 and 5.2.1.2). Please verify.