Description: Images in Calc get lost even in the newest version of Libreoffice 24.2.0.3 For my business I have to work on large excel files with more than 500 lines of products. Every line has an image in the third column embedded in the cell. After some manipulation of the file (adding quantities, costs etc) some images are lost completely from the document. In the past there was a bug where the images were moved to the top of the file (https://bugs.documentfoundation.org/show_bug.cgi?id=153166) which was solved in the newer version of Libreoffice, but now they are randomly completely removed and cannot be restored. This of course troubles me the last two years and is the only reason I am forced to use a virtual machine with windows and microsoft office in my linux mint machine to work on these files! A solution would be highly appreciable. The past 2 years I have tried the following: 1. Saving from Microsoft Office 2010 to xls 2. Saving from Microsoft Office 2010 to xlsx 3. Saving from Microsoft Office 2010 to ods Working with all these formats again leads to the same bug, after some manipulation of the file images are getting randomly removed from their corresponding cells. Also I have tried moving every image to the center of their cell. For this I have attempted to do it manually for all 500+ images and also I wrote a VBA script in MS Office to do it automatically. Also with this VBA script I changed the setting of every image to "move but don't size with cells" but this again didn't make any difference! Also, I recently uninstalled the Libreoffice from the official repository and installed the latest version 24.2.0.3 directly. This looked promising but I saw the bug again and I verified it with all the above file formats (xls, xlsx, ods)!! Steps to Reproduce: I will upload the sample file in ods format with more than 500 of lines and images. 1. Manipulate the file by adding quanities, resizing columns or lines, adding infos etc in order to trigger structural changes. 2. Save and reopen and check if images are lost from the third column on random lines. 3. If not continue manipulating, save and reopen until you see images missing. Actual Results: Images are randomly getting lost from cells after manipulating the file. Expected Results: Images should stay positioned to their original positions, locked to their corresponding cells after manipulating the file. Reproducible: Sometimes User Profile Reset: No Additional Info: Where can I upload the sample file????
Created attachment 193145 [details] An ods file containig 550 lines with images
It is very important bug; but please provide the *exact* action sequence that gives the problem. Please record every action you did while reproducing the issue. Without that, the "adding quanities, resizing columns or lines, adding infos etc" is not something one can realistically try and hope to see the problem (everyone can do their own set of actions). For instance, I opened the file, checked that Navigator shows "698 images" as tooltip for Images category, then resized the column G (made it wider), put "1" to G6, drag-copied it till G561, and added data "1", "q", "", "qwe" to A562:D562. Saved it as another ODS, and reopened. The "Images" category still shows 698 images, and I can't see any problems easily.
FTR: I tested using Version: 24.2.2.1 (X86_64) / LibreOffice Community Build ID: bf759d854b5ab45b6ef0bfd22e51c6dc4fb8b882 CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded
You are right, of course I understand the need to have very specific steps but I couldn't find a deterministic sequence to reproduce it. I'll try to be more methodic and return with more infos. At this point would the corrupted file be useful, should I uploaded too?
I was testing the file with Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6a064b1967e06e40be40817deff99d00c1a8554f CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded And I wasn't able to anyways to unintentionally delete random images. Is this problem only replicable in Linux? You've never had this issue with the virtual machine with Windows?
(In reply to MB from comment #4) > At this point would the corrupted file be useful, should I uploaded too? Possibly. Potentially, there could be changes there, that could help see what the problem could look like; maybe the images are there, but displaced; maybe the problem is very tall rows... yes, it could be useful.
I'm struggling with the this bug also. In my case it happens when I apply a filter on and off. If I save the document afterwards, then many images are "lost". Actually the images are not lost, they are at just very different locations in the document or not visible anymore. I made sure that every image is anchored to the cell but this bug still happens. As a work-around the bug I either: - filter the document and view it without saving afterwards - change the document without filtering This way the images stay in their positions and everything looks good. When I open the ods file as zip file, all images are still contained in the file. So for me it is very reproducible.
(In reply to wjsim from comment #5) > I was testing the file with > > Version: 24.2.1.2 (X86_64) / LibreOffice Community > Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac > CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: CL threaded > > Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 6a064b1967e06e40be40817deff99d00c1a8554f > CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: CL threaded > > And I wasn't able to anyways to unintentionally delete random images. Is > this problem only replicable in Linux? You've never had this issue with the > virtual machine with Windows? I have never used Libreoffice in Windows so I have no feedback on that. There is no need or plan to use Libreoffice in Windows as I don't use Windows in general, and this is my frustration, in order to use this excel file I had to install virtual machine with windows and MS Office.
(In reply to Urs Weder from comment #7) > I'm struggling with the this bug also. > In my case it happens when I apply a filter on and off. If I save the > document afterwards, then many images are "lost". > Actually the images are not lost, they are at just very different locations > in the document or not visible anymore. > I made sure that every image is anchored to the cell but this bug still > happens. > > As a work-around the bug I either: > - filter the document and view it without saving afterwards > - change the document without filtering > This way the images stay in their positions and everything looks good. > > When I open the ods file as zip file, all images are still contained in the > file. > > So for me it is very reproducible. To my knowledge the sample file I have uploaded doesn't have any filters. You can check of course yourself. To be honest I don't even know what filters are... So I'm not sure if my problem is related to filters. It looks like the anchoring on the cells gets broken.
Created attachment 193254 [details] Corrupted test file which exhibits the lost images from the cells
Created attachment 193261 [details] Sample 1. Open the attached file (identical as attachment 193145 [details] except auto filter being added and a few rows deleted) 2. Column C has pictures everywhere 3. Select filter arrow in A2 and sort descending (doesn't really matter where you filter or how) 4. The image for for example row 96 (KDH-XM-0224-06) will be gone (there are more) Those are not really not deleted bit tiny 1x1 pixel (or something like that) moved into in the wrong cell.
@Telesto, why did you removed the Linux (All) Tag and declared it Windows (All)? I first noticed the issue in Linux... I believe though that the bug is internal and not based on the operating system... Personally I would prefer it declared for Linux as this bug forces me to use Windows and MS Office, so a solution in Linux would be really important. Maybe we could select "All"
(In reply to Telesto from comment #11) Well I spoke to soon. Hidden rows becoming without image becoming visible when using the auto-filter.. @MB Setting it to Windows was a mistake.. Intended to set it to 'All'. I will set it back to Linux for now. I'm unable to figure out how to trigger the problem at this point
I have spent a couple of hours trying to reproduce the problem and I indeed reproduced it 3 times, but I still haven't found a reproducable methodology to do so. It looks to me pretty random and could be a race condition. For example because of the large number of images could be that in a fast scroll some pictures are not rendered or not correctly loaded in ram and then in the next save they are not correctly saved in the file. If it is a race condition the cpu and the ram of the computer can also affect the issue. My computer has 32GB Ram and 6700K CPU so I consider it powerful enough. What I tried to do in order to reproduce are the following: - Go to line 6 and select View > Freeze Rows and Columns - Add content to lines 1 to 3 in all columns with borders - Resize lines 1 to 4 - Freeze and unfreeze line 6 from time to time - Scrolling to the line 561 and back to 1 several times Doing the above many times and saving several times sometimes you see images missing. One of the first images to get lost is at line 107. Line numbering refer to lines of Libreoffice not the numbering of the ods itself.
Created attachment 193299 [details] Another corrupted file after my last attempts to reproduce the issue This is another corrupted file produced after my attempts described in https://bugs.documentfoundation.org/show_bug.cgi?id=160231#c14
It is very interesting to compare the first corrupted file (2024-03-23 08:16 UTC) with the second corrupted file (2024-03-25 17:22 UTC). Missing are more or less the same images but not all! Some images never get missed. Some images are missing in both files and some images are missing only in one file!!!
I just made a very important discovery: the "images" missing are not actually just images but groups!! So probably they are "objects" not images. Looks like libreoffice has issue with groups!
Finally, I managed to find the exact steps to reproduce the issue!! 1. Open the first file attached here (test06.ods 2024-03-16 16:41 UTC) 2. Go to line 106 of Calc not the content. Resize the "image" (it is a group actually) downwards up to the end of the line 107, so as to overlap and cover completely the image of the line 107. 3. SAVE 4. Go to line 6 of Calc not the content. Select View > Freeze Rows and Columns 5. Go to line 1 of Calc not the content. Resize it to height 1cm 6. SAVE 7. Go to line 106 of Calc not the content. See that "image" is missing together with images at lines 107, 110, 139, 145, 146 etc...
(In reply to MB from comment #18) > Finally, I managed to find the exact steps to reproduce the issue!! For these steps at least, the underlying issue is that the cell anchor changes on save. I could reproduce as described, but trying to find a smaller set of steps, I found: 1. Open attachment 193145 [details] 2. Go to row 106 3. Save Result: group is now anchored to cell C107, even though its top-left corner is still in cell C106. Clicking the group does not seem to work, one has to click below, as if it was moved down. A reload of the file brings it back to cell C106. However, a _second_ save will make the object stay at cell C107 - so I think that's the essence of it, regardless of the extra intermediate steps you listed: saving twice makes the wrong anchor stick, with the obvious consequences when further manipulating the file. Note that resizing an object can move its anchor to a different cell, but it usually happens transparently and instantaneously (anchor is where top left corner is; happens as soon as resizing is finished. In this case, no resizing is needed. I've reported this 7.1 regression in the new bug 160369, for clarity. Marking this report as a duplicate. *** This bug has been marked as a duplicate of bug 160369 ***
@stephane.guillou Unfortunately I completely disagree with you and I was really upset sawing that you marked this bug as duplicate. Let me explain. First of all did you notice that with my methodology many images (which are in fact groups) get lost and the problem is not only "image" at row 106? Secondly, In my everyday usage of the file I never resize or move images, they are all in the middle of their cells anchored there and I never touch them. But after some edits and saves this happens again. People asked me to create a methodology to replicate the issue for them to see it and I searched for it showing a methodology but this doesn't mean this is the real problem. It's just a way to see with your own eyes the proof that there is an issue. My bug report here so refers to the random lost of "images" (which proved to be image groups) when editing the file, not when resizing the images. If you mark this as duplicate the issue here is closed and all the info that comes with it. I spent too much time on this to accept your last comment as the same as my issue. What you describe is another issue. If you find the reason why the group of images are lost without any resize of them just by editing the document, I may accept that it is related...
@stephane.guillou It is very important to understand that with my steps all the image groups in the document get lost, not only on row 106. And the target is to find an even better reproduction methodology that will make these images get lost without any resize of them.
@MB To be clear. Something is really really broken regarding to anchored images (and especially with hidden rows). There are now multiple show cases: bug 147420 bug 152635 bug 160369. It surely broken since 6.1 and it didn't work properly before 6.1. The experiences are varying from case to case. A developer needs to start working and the issues to untangle the mess. It will show if all issues being unique by itself needing a fix individually or if a shared root cause exists. It can't be assessed in advance. Time will tell QA members are inclined to keep the bugtracker tidy and clear. So bugs are marked as duplicate looking at the shared property (and less on uniqueness). The duplicates are (ideally) re-checked after the fixes landed. So the idea is not to hide the issue under the carpet --- FWIW: Your are right regarding to the aspect of grouped images. It also a factor involved. Grouped images act a bit different compared to normal images. The images don't appear to be lost, IMHO. The can be seen in the the navigator. The are moved to wrong cell hidden behind different image and being shrunk to tiny dimensions.
(Telesto replied before me but here's my original reply anyway.) (In reply to MB from comment #20) > Unfortunately I completely disagree with you and I was really upset sawing > that you marked this bug as duplicate. Let me explain. Sorry that upset you, but let me clarify what the process usually is: - someone reports an issue. - if we don't have precise steps to reproduce the bug, there isn't much we can do to fix the problem - once we have steps, we often try to minimise them to really pinpoint what the root problem is - that allows developers to zero into where in the code the process fails, and eventually fix it > First of all did you notice that with my methodology many images (which are > in fact groups) get lost and the problem is not only "image" at row 106? As said above, we focus on a precise, reproducible example so we can investigate further. I understand other groups are affected in your document, I am not ignoring that. > Secondly, In my everyday usage of the file I never resize or move images, > they are all in the middle of their cells anchored there and I never touch > them. But after some edits and saves this happens again. People asked me to > create a methodology to replicate the issue for them to see it and I > searched for it showing a methodology but this doesn't mean this is the real > problem. It's just a way to see with your own eyes the proof that there is > an issue. And thank you for finding those steps. It allowed me to look further into it. > My bug report here so refers to the random lost of "images" (which proved to > be image groups) when editing the file, not when resizing the images. The groups are in fact not lost. They are moved elsewhere. If you repeat the steps you gave us in comment 18, you will still be able to find the group we used as an example "组合 166", you can see it in the Navigator and double-click it to select it. It was moved down in the sheet. > If you > mark this as duplicate the issue here is closed and all the info that comes > with it. I spent too much time on this to accept your last comment as the > same as my issue. And we appreciate you taking the time to help out! The information is not lost, it available publicly and isn't going anywhere. Often, when a bug is fixed, QA will check that indeed everything described in the duplicates is also fixed. And when bug 160369 gets fixed, you can check that it indeed resolved your overall issue. Duplication is important so we can focus our attention on root causes of problems. You will find many reports on this bug tracker that are marked as duplicates of one issue even though the symptoms described are _very_ different. Sometimes, a bug has many different consequences. > What you describe is another issue. From the information we have, and to the best of my knowledge, bug 160369 is the root cause (or at least one of the causes) of your problem. Other related problems that need fixing are, for example, bug 160329, bug 152635, bug 147420. > If you find the reason why the group of images are lost without any resize > of them just by editing the document, I may accept that it is related Bug 160369's steps does not require any resizing. And again, the group is not "lost", it is merely moved. Does that make more sense?
I appreciate the time you spent to explain. I trust you and if you believe all the other issues you have in mind have the same root cause as this please make it a duplicate. I just want to emhasize that for my everyday usage the important thing is that not only one image is lost but all group images. If it was only one image after a random resize I would be ok, but losing all images randomly and without resize doesn't allow me to use Libreoffice for this job at all, because every now and then the document get's corrupted. So please check if with your shortened reproduction methodology if the other group images are lost. I added very carefully the extra steps with freeze and resizing the first line in order to produce the losing of images in the other cells too. Your oversimplification in these steps I'm afraid will not pinpoint the lost of all other group images in the document
Thank you. Indeed, following the same bug 160369 steps, we can see the same issue with rows 112, 115, 144, 150... and many more. So we've got the "many groups affected" issue covered. To see it, you can save the file, then zoom in and out so the view refreshes and the group "ghosts" disappear. I even noticed that some disappear only on the second save. e.g. row 151. Marking as duplicate again, and I'll add these extra details to the other report. *** This bug has been marked as a duplicate of bug 160369 ***
(In reply to Stéphane Guillou (stragu) from comment #25) And indeed, for the *actual work* on that, additional simplification will be needed - at least by the developer - to remove *everything* from the document, except for the very minimal set required to repro the problem in one single object. E.g., my process would be removing all objects except the one that you identified in row 106; remove all the text; remove all columns except the one with the object; and then try to reproduce with the described steps. If it reproduces, that is almost ideal bugdoc for the purpose of further work.
(In reply to Stéphane Guillou (stragu) from comment #25) > I even noticed that some disappear only on the second save. e.g. row 151. (Scratch that: problematic groups just keep moving down at each save. Row 151 was affected from the beginning, it just didn't seem to be the case because it received the object from the previous row on first save.) (In reply to Mike Kaganski from comment #26) > And indeed, for the *actual work* on that, additional simplification will be > needed Good point, original file is huge. Done in bug 160369 comment 6. So turns out it's related to the hidden row, so very much related to bug 160329.