For some Calc files (always the same), the save button is active without having made any modification. So, if I just open a file to read it, I can't close it without obtaining the message saying that the document was modified. I join two documents examples (with and without this default) with a slight difference: the choice of different data for one of the curves of the last sheet This problem is reproducible with the same files as well with OOo 3.2 OOo 3.3 and LibO, and on two OS (Vista and 7).
Created attachment 39898 [details] Example of a defective file Just open it and look at the save button (bad)
Created attachment 39899 [details] Example of a correct file Just open it and look at the save button (good)
Created attachment 39960 [details] Various case showing the relation of the function INDIRECT with the issue
Here are observations which can help: The bug comes from the use of the function INDIRECT together with the use of the results in a graph (joined example : “modif-bad”) - a similar file without the function INDIRECT does not raise problem (joined example “modif-ok1”) The use of results of the function INDIRECT in calculations and others functions does not create the problem (joined example : “modif-ok”).
Let me look into this.
Unfortunately there are gazillion places that set a document modified flag during import. I've only taken a cursory look at it, but the prospect doesn't look too good.
Also reported in Oracle's issue tracker http://www.openoffice.org/issues/show_bug.cgi?id=114589
NOT reproduced with Ubuntu 10.04.2 x86 LO 3.4
(In reply to comment #8) > NOT reproduced with > Ubuntu 10.04.2 x86 > LO 3.4 Indeed, it seems that this issue is fixed with Libo 3.4
Unfortunately, this bug which was fixed in version 3.4, comes back in version 3.5! The behaviour is exactly the same with files previously joined. I hope really that this can help you, because it is very confusing. [LibO 3.5.1 rc2]
Changed 'Component' to 'Spreadsheet', therefore 'Summary' abbreviated.
Seems fixed in version 4.0.4 so marking as WFM - if this is still an issue for you in version 4 mark as NEW again. Thanks!
Thanks to follow this issue You are right, It's Ok with 4.0.4.2 but still wrong with: Version: 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155 and Version: 4.2.0.0.alpha0+ Build ID: 5b9bad7482a98f2d0d37c4b75a13292abe653ea3 [All tests performed with attachments on Vista-32b] Therefore I reopen the bug Regards
Works as expected in LibO 4.2.5.0.0+ but not in LO 4.1.6 (generic Linux version 64 bits) and in the master (Build ID: d1ffea3a272d61f1343047e86b4eeabe032aa352) Best regards. JBF
As there is confusion as to if this bug is still reproducible, moving back to UNCONFIRMED to let QA team try to get a handle on what's going on. Thanks
Tested attachment 39898 [details]. On Windows and 4.4 alpha, the problem doesn't exist. On Ubuntu 4.4 alpha, 4.3.3.2 and Windows 4.3.4.1, the save button is active and it prompts to save on close. Win 7 64-bit 4.3.4.1 and Version: 4.4.0.0.alpha2+ Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827 TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08 Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+ Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29 and Version: 4.3.3.2 Build ID: 430m0(Build:2)
Not reproducible with my own build of master (Version: 4.4.0.0.alpha2+ Build ID: 6b30907a926890f835c094a5afdf4c0e6d8a1d19) under Ubuntu 14.10 x86-64 But reproducible with my own build of 4.3.5.0.0+ (Build ID: 547d613e0868726e602ccb00fca0e7518a6c4bee) under Ubuntu 14.10 x86-64 Best regards. JBF
Reproduced on Linux with OOo 3.3.0, LO 3.3.0 and current 4.5 master (5cfee95f4e611911a862788370402e861531e9c1) -> Version: Inherited from OOo -> Platform: All
** 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.0.5 or 5.1.2 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
In LO 5.1.3.0.0+, both testfiles are tagged modified as soon as they are opened, no matter the answer I give to the question if all formula must be recalculated because the file has been saved by another application than LibreOffice. Best regards. JBF
** 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.2.7 or 5.3.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-20170522
Both files open as modified in LO 5.3.3 from Ubuntu PPA, LO 5.3.5.0.0+ built at home and LO 5.4.0.0.beta2+ built at home. Ubuntu 16.04 x86-64 Best regards. JBF
So this issue happens with any document that has a chart in it, likely because it needs to refresh the image rendering of the chart in the document, as can be tested with any of the below files. http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/odp/chart.odp http://cgit.freedesktop.org/libreoffice/core/plain/chart2/qa/extras/data/ods/chart.ods (In reply to Michel Rudelle from comment #2) > Created attachment 39899 [details] > Example of a correct file > > Just open it and look at the save button (good) Opening this file in master has the save button enabled (aka bad). It went from good to bad in 5.0. Version: 6.0.0.0.alpha0+ Build ID: 7315f325ff7ada3d6bd85a471058fdaeaff8cdb0 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-17_06:58:21 Locale: en-US (en_US.UTF-8); Calc: group @Eike: Any thoughts?
Interesting how this bug, opened for pre-LO versions, then reported to be WFM twice, is now used for problem that had begun for 5.0 after being OK in 4.4... Well, however, will post the bibisect here. /cygdrive/d/sources/bibisect-win32-5.0 $ git bisect log # bad: [b7988d11e5d3751a4b366b2bfc9048f7a30e8526] source 87ac0b1e75a880a68ecb748bd4b34ae5a3d2ae98 # good: [f449493ae11ac76cc7396bddeaa624a60c565936] source 57d6b92b69a31260dea0d84fcd1fc5866ada7adb git bisect start 'master' 'oldest' # bad: [66e2ae767eb4bb83444e3d03bcb90adcbe6d4991] source 5a308b1239a09417507b0d05090ff2d3418d5133 git bisect bad 66e2ae767eb4bb83444e3d03bcb90adcbe6d4991 # bad: [90c1dbb098a6d957f2293692716251ee5a6053ca] source 2813632238380e0bfe40c0e6404a07102cde1398 git bisect bad 90c1dbb098a6d957f2293692716251ee5a6053ca # good: [5b8e174eb7b3d996d6c90862d7228e1b928a9787] source 4de09a9efdb62cf90ce18662852e556cf7148e14 git bisect good 5b8e174eb7b3d996d6c90862d7228e1b928a9787 # good: [5d530472220267ad6588480f7a67a8f28f83d070] source ff2990fded4f1745c44f62cca53e3bff28e371fb git bisect good 5d530472220267ad6588480f7a67a8f28f83d070 # bad: [1f0e00b205dd7bd5e9d2cd0ce1e61fcbb7da78ac] source 7b1261f6f956271ec2a545f635e11432a5e64fa1 git bisect bad 1f0e00b205dd7bd5e9d2cd0ce1e61fcbb7da78ac # good: [95352698710d22573b9f43c92fddc73a48f5f64e] source 8d98f035cf6c410d4b29bd58d86cfe86127db68b git bisect good 95352698710d22573b9f43c92fddc73a48f5f64e # bad: [6d37964763973590a141432004ce89ed14fbdb02] source 6123d6a9fbb268f823224d054cb0fe215aa3015a git bisect bad 6d37964763973590a141432004ce89ed14fbdb02 # good: [06e434742b9befe90f6c1f0cd5c1abacab00a868] source de7a5eb44f942054c42157bf9243fb89a1d39368 git bisect good 06e434742b9befe90f6c1f0cd5c1abacab00a868 # bad: [a046e35d5a4e4e62978ee091be9c7fdd8d6eba68] source 1b5c8e4a031af17c47a2900da09c1db1df1242df git bisect bad a046e35d5a4e4e62978ee091be9c7fdd8d6eba68 # bad: [ada1916a118c4aa6cc39722e39c885edd8120480] source c29657e0d6bb707345584ac7a7f5ae5016f37297 git bisect bad ada1916a118c4aa6cc39722e39c885edd8120480 # good: [ba326ca77713f2080a89e95181afdbdc2e11039f] source d1ce6effb62745e9f9c85badd44a1be0aa4a1d8f git bisect good ba326ca77713f2080a89e95181afdbdc2e11039f # bad: [75fba066c605374e1d4bb2a9f15b81e2eef192e9] source dc28e90d200a839d4017d548217ee5ce8a23f848 git bisect bad 75fba066c605374e1d4bb2a9f15b81e2eef192e9 # good: [870b1afa9d74304494e209b0bd9f24dfe4127bef] source 465356ecc81e23016b4289ab16e99084f2a7b84e git bisect good 870b1afa9d74304494e209b0bd9f24dfe4127bef # first bad commit: [75fba066c605374e1d4bb2a9f15b81e2eef192e9] source dc28e90d200a839d4017d548217ee5ce8a23f848 https://cgit.freedesktop.org/libreoffice/core/commit/?id=dc28e90d200a839d4017d548217ee5ce8a23f848 author Noel Grandin <noel@peralex.com> 2014-12-25 13:17:55 (GMT) committer Noel Grandin <noel@peralex.com> 2015-01-06 08:59:41 (GMT) commit dc28e90d200a839d4017d548217ee5ce8a23f848 tree a6ae872fb19a046292d96d280da286a20a397def parent 465356ecc81e23016b4289ab16e99084f2a7b84e fdo#84938: convert IMPORT_ constants to 'enum class'
Since it's unclear to me why could that commit cause this problem, I re-bibisected on Ubuntu: ~/bibisect-50max$ git bisect log # bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86 # good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311 git bisect start 'latest' 'oldest' # bad: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d git bisect bad 0c30a2c797b249d0cd804cb71554946e2276b557 # bad: [770ff0d1a74d2450c2decb349b62c5087e12c46b] source-hash-549b7fad48bb9ddcba7dfa92daea6ce917853a03 git bisect bad 770ff0d1a74d2450c2decb349b62c5087e12c46b # good: [227af65db5e34efcf8dcb0b53333efecd30f37f8] source-hash-193c7ba9be48f00b46f9e789f233db577e7b3303 git bisect good 227af65db5e34efcf8dcb0b53333efecd30f37f8 # good: [78b395d05689a5207f2ec4cc29ec296d64076a96] source-hash-a2e4be6ded508030a6c2a33919cbe8cb504382e0 git bisect good 78b395d05689a5207f2ec4cc29ec296d64076a96 # good: [8dd6442885c969ae43ae5ff9ddfc53c9f04a9c27] source-hash-d07f0997c54e9cef31d996ebeb2aabfb4b4e0265 git bisect good 8dd6442885c969ae43ae5ff9ddfc53c9f04a9c27 # good: [56e2ff1d44b7bcd4fff6ce86c93fd9b666808d0b] source-hash-d7794d2584cd5d476b011b5344c77ad59c179c58 git bisect good 56e2ff1d44b7bcd4fff6ce86c93fd9b666808d0b # good: [4f5bf35bab35f426249aa06c92be46174890a379] source-hash-df5fa4082cfb17c5d5be6678995689485df6d429 git bisect good 4f5bf35bab35f426249aa06c92be46174890a379 # good: [086887d27fcae1b0e65a150051c179e27721a341] source-hash-2eb4bd3c8ce8d4ac76680e5179364b12a656ae94 git bisect good 086887d27fcae1b0e65a150051c179e27721a341 # good: [0889bdba9a9cc0a9aa801dc90fc3ec47004ba6a5] source-hash-d1ce6effb62745e9f9c85badd44a1be0aa4a1d8f git bisect good 0889bdba9a9cc0a9aa801dc90fc3ec47004ba6a5 # bad: [6dca089c8fd025a2fe843d886635b7ba649d8450] source-hash-abe670157b69aa7fe4b478f1fd13757d7b7fcc4b git bisect bad 6dca089c8fd025a2fe843d886635b7ba649d8450 # bad: [eb18d55b7b5df079783a35286333fcda73870115] source-hash-c29657e0d6bb707345584ac7a7f5ae5016f37297 git bisect bad eb18d55b7b5df079783a35286333fcda73870115 # bad: [0f0b8c55f1bd241bd2cc274907413ebec6304c39] source-hash-dc28e90d200a839d4017d548217ee5ce8a23f848 git bisect bad 0f0b8c55f1bd241bd2cc274907413ebec6304c39 # good: [851ab1111c5e731876d919e84f099b6aa293f4fb] source-hash-465356ecc81e23016b4289ab16e99084f2a7b84e git bisect good 851ab1111c5e731876d919e84f099b6aa293f4fb # first bad commit: [0f0b8c55f1bd241bd2cc274907413ebec6304c39] source-hash-dc28e90d200a839d4017d548217ee5ce8a23f848 So, the result is the same.
Bug 86321 comment 29 mentioned that this commit had fixed an issue with a diagram not updated on source data edit.
Well, on the second glance, it turned out that the commit did change logic in one place: sc/source/filter/xml/XMLTableShapeResizer.cxx. Given that SvXMLImportFlags::ALL is a bitmask 0xffff, the new code started to check if any bit is set, instead of checking for exact match. A patch is https://gerrit.libreoffice.org/44396. This is for the regression in Calc. The Impress thing seems to have not working at the time of the regression, so should be fixed separately. Please create a proper issue for it. (This issue looks invalid anyway.)
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f657454b69c813b90a8b3c1adb2feef1066dbd35 tdf#31231: properly check for SvXMLImportFlags::ALL It will be available in 6.0.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.
*** Bug 113689 has been marked as a duplicate of this bug. ***
For what it's worth, defaut.ods still opens displaying the modified dot on the Save button. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha1+ Build ID: 1aba1955f161cc112dab80b6b3e78ec7761616fc CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 10th 2017
*** Bug 114121 has been marked as a duplicate of this bug. ***
*** Bug 114547 has been marked as a duplicate of this bug. ***
Dear Mike Kaganski, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Adding Cc: to Noel Grandin
Bug still present: Version: 6.2.3.2 (x64) Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded
I confirm, this bug is still present: Version: 6.2.3.2 Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac Threads CPU : 4; OS : Linux 4.13; UI Render : par défaut; VCL: gtk3; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded Ubuntu 18.04.2 LTS Gnome 3.28.2
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3e6519714abebf00637c953dbba055d620cfe6f7 tdf#31231: don't set charts modified state when !IsEnableSetModified It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/21a73161caebd26429ac7df40adf3183852e0bdc tdf#31231: don't set charts modified state when !IsEnableSetModified It will be available in 7.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-0-0": https://git.libreoffice.org/core/commit/0a01a61bd582df5bce8a627f6ed56c1b7e680218 tdf#31231: don't set charts modified state when !IsEnableSetModified It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Just tested. It works fine LO 7.0, W10
(In reply to Pierre C from comment #40) Thanks for testing; let's call it fixed then. Any similar problems must go to a separate bug reports (add this to "See Also" if necessary).
This issue is happening again since https://cgit.freedesktop.org/libreoffice/core/commit/?id=574eec9036c5f185b3572ba1e0ca9d111eb361dc Reported in bug 141914