[Bug 160231] Images in Calc get lost (steps in comment 18)
https://bugs.documentfoundation.org/show_bug.cgi?id=160231 --- Comment #27 from Stéphane Guillou (stragu) --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160231] Images in Calc get lost (steps in comment 18)
https://bugs.documentfoundation.org/show_bug.cgi?id=160231 --- Comment #26 from Mike Kaganski --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160231] Images in Calc get lost (steps in comment 18)
https://bugs.documentfoundation.org/show_bug.cgi?id=160231 Stéphane Guillou (stragu) changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REOPENED|RESOLVED --- Comment #25 from Stéphane Guillou (stragu) --- 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 *** -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160231] Images in Calc get lost (steps in comment 18)
https://bugs.documentfoundation.org/show_bug.cgi?id=160231 --- Comment #24 from MB --- 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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160231] Images in Calc get lost (steps in comment 18)
https://bugs.documentfoundation.org/show_bug.cgi?id=160231 --- Comment #23 from Stéphane Guillou (stragu) --- (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? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160231] Images in Calc get lost (steps in comment 18)
https://bugs.documentfoundation.org/show_bug.cgi?id=160231 --- Comment #22 from Telesto --- @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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160231] Images in Calc get lost (steps in comment 18)
https://bugs.documentfoundation.org/show_bug.cgi?id=160231 MB changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #21 from MB --- @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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160231] Images in Calc get lost (steps in comment 18)
https://bugs.documentfoundation.org/show_bug.cgi?id=160231 --- Comment #20 from MB --- @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... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160231] Images in Calc get lost (steps in comment 18)
https://bugs.documentfoundation.org/show_bug.cgi?id=160231 Stéphane Guillou (stragu) changed: What|Removed |Added See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=14 | |7420| -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160231] Images in Calc get lost (steps in comment 18)
https://bugs.documentfoundation.org/show_bug.cgi?id=160231 Stéphane Guillou (stragu) changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Summary|Images in Calc get lost |Images in Calc get lost |even in the newest version |(steps in comment 18) |of Libreoffice 24.2.0.3 | --- Comment #19 from Stéphane Guillou (stragu) --- (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 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 *** -- You are receiving this mail because: You are the assignee for the bug.
