Description: Images disappearing when editing text in libre writer. I recorded a video. Its hard to reproduce same steps because it happens rarely. And there are lots of bugs happaning when i editing text. I changed text body to default style then bullet style added to all parapraphs which was not an important bug. Because theres workaround. But when an image disappeared and if i ctrl+s(save) next time image disappaeres forever. Rare occasions image comes back from nowhere. ill also attach my document. so maybe you can use it to solve issue. MAterial is just study notes from turkish history, so dont worry. Steps to Reproduce: Moving images, objects. Actual Results: Images disappearing and doesnt come back. Expected Results: Images should move freely witout being erased?? Reproducible: Sometimes User Profile Reset: No Additional Info: I have video of whats really happening. You can actualy watch it instead of reading steps. https://youtu.be/9t3rF8YvtIQ Also .odt document : https://dosya.co/0woke2dn7dzc/Cumhuriyet_Dönemi.odt.html Have a good day.
Created attachment 162927 [details] Example file
Do you still have the original file including the missing image?
Created attachment 162934 [details] the missing image the missing image.
Created attachment 162935 [details] original .odt file
(In reply to Telesto from comment #2) > Do you still have the original file including the missing image? yep just uploaded both. But since image has disappeared dont know if it still includes that image.
(In reply to mucahitduran from comment #5) > (In reply to Telesto from comment #2) > > Do you still have the original file including the missing image? > > yep just uploaded both. But since image has disappeared dont know if it > still includes that image. True, but idea is to make it disappear again following your steps seen in the screencast. The image is really gone in the initial file..
File contains a multitude of problems :-( Created a few separate reports for them. Not sure if found all problems already
Created attachment 162957 [details] Screencast 1. Open attachment 162935 [details] 2. Press Enter after kurulmuştur -> Bullet appears, shouldn't 3. Drag the image towards the bullet -> Anchor at bullet 4. CTRL+Z 5. CTRL+Z 6. CTRL+Y -> Image gone
This and bug 134773 are likely the same thing
Created attachment 163833 [details] bibisect-linux-64-6.4, tail of terminal output (In reply to Telesto from comment #8) > 5. CTRL+Z > 6. CTRL+Y -> Image gone Like in the attached screencast, the image disappears after *two* <ctrl>+Y. Working in bibisect-linux-64-6.4 on debian-buster, I see: commit s-h date good 9a56bb97 22f2ecbc 2019-07-22 04:36:27 bad 6d81b91b 28b77c89 2019-07-22 06:32:07 The commit message starts: commit 28b77c89dfcafae82cf2a6d85731b643ff9290e5 Author: Michael Stahl <Michael.Stahl@cib.de> AuthorDate: Thu Jul 11 18:37:28 2019 +0200 Commit: Michael Stahl <Michael.Stahl@cib.de> CommitDate: Mon Jul 22 08:32:07 2019 +0200 tdf#117185 tdf#110442 sw: bring harmony & peace to fly at-char selection Use IsDestroyFrameAnchoredAtChar() to harmonize the at-char fly selection across all relevant operations: I am removing keyword bibisectRequest, adding bibisected and bisected. I am setting blocked bug 103152 and bug 105948.
Adding CC: to Michael Stahl
This strange ODT is now in multiple bugs (wrongly uploaded more times, instead of just writing attachment number, so harder to find). If large part of images is deleted, they remain in the ODT. Also crash on large delete. I didn't see tracking enabled. Writing by memory now, as a warning to Michael. My view is that only crash is a valid bug.
(In reply to Timur from comment #12) > This strange ODT is now in multiple bugs (wrongly uploaded more times, > instead of just writing attachment number, so harder to find). This is the source bug, if you need to now. See they see also for list for rest > If large part of images is deleted, they remain in the ODT. Also crash on > large delete. Crash is already solved
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f3cb59c46398b3a0646b8b374d5626f715fa6884 tdf#134746 sw: fix redline hiding of at-char fly on empty paragraphs 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.
hope i fixed it on master
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/7e40584e8945ee555f8ad4584c5b2c95a8c6dde6 tdf#134746 sw: fix redline hiding of at-char fly on empty paragraphs It will be available in 6.4.7. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/9f18678432086ccf659bd9d4cbadc7e09f800897 tdf#134746 sw: fix redline hiding of at-char fly on empty paragraphs It will be available in 7.0.2. 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.
Telesto, Are there other reports which you should revisit to see if their reported behavior has changed? Of course, once you see for yourself that this bug is fixed, you should advance the status to VERIFIED FIXED.
Solved Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
(In reply to Terrence Enger from comment #18) > Telesto, > > Are there other reports which you should revisit to see if their > reported behavior has changed? > > Of course, once you see for yourself that this bug is fixed, you > should advance the status to VERIFIED FIXED. I don't re-call a specific case where this was an issue. However, forgive me don't oversee my own mountain. Nor everything else what's floating around in the bugtracker. However I noticed that there is quite a need to report sometimes "infuriating" amount of variants, until everything is covered. If I report low amount (assuming it to be the same), lots of bugs are missed. So I might overreport. Patches clearly patch report in question. So often only that specific part. With some luck it squeezes a few more. With bad luck it created plenty of new. It's clear to me that the code base is big/ and number of possibility's rather large the similar type of fix must be done all over the place. Someone who implemented highlighting in Impress forgot presentation mode. Someone who enabled highlighting in textboxes for ODT forgot DOC/DOCX. Someone who updated the fontwork styles forgot comp-ability with DOCX (those cases could be prevented) Something else is the "sw: bring harmony & peace to fly at-char selection". The commit was really needed, but the fall-out is still popping up in different corners. I'm partly responsible for all of that. As the whole change was initiated by my crash report. Overall - long term - for the better (I assume), but large bugs 2 squeezed, 10 smaller - but still problematic - problems introduced. And VERIFYING matter, I surely don't check fixed on a daily basis. I assume those fixed; I personally see VERIFICATION bit of formality.
(In reply to Telesto from comment #20) > And VERIFYING matter, I surely don't check fixed on a daily basis. I assume > those fixed; I personally see VERIFICATION bit of formality. I just remember that setting VERIFIED is a standard part of the process. I do not know who uses the distinction between RESOLVED and VERIFIED. Perhaps that would be a good question for the QA list.