Download it now!
Bug 134746 - Images disappearing when editing text in libre writer (tracking changes enabled)
Summary: Images disappearing when editing text in libre writer (tracking changes enabled)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.4.2 release
Hardware: All All
: medium normal
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: target:7.1.0 target:6.4.7 target:7.0.2
Keywords: bibisected, bisected, dataLoss, regression
Depends on:
Blocks: Writer-Images Undo-Redo
  Show dependency treegraph
 
Reported: 2020-07-12 08:07 UTC by mucahitduran
Modified: 2020-08-18 23:22 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (13.57 MB, application/vnd.oasis.opendocument.text)
2020-07-12 15:38 UTC, Telesto
Details
the missing image (74.63 KB, image/jpeg)
2020-07-12 19:27 UTC, mucahitduran
Details
original .odt file (14.00 MB, application/vnd.oasis.opendocument.text)
2020-07-12 19:31 UTC, mucahitduran
Details
Screencast (856.49 KB, video/mp4)
2020-07-13 08:41 UTC, Telesto
Details
bibisect-linux-64-6.4, tail of terminal output (2.97 KB, text/plain)
2020-08-01 01:19 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mucahitduran 2020-07-12 08:07:18 UTC
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.
Comment 1 Telesto 2020-07-12 15:38:04 UTC
Created attachment 162927 [details]
Example file
Comment 2 Telesto 2020-07-12 19:16:18 UTC Comment hidden (obsolete)
Comment 3 mucahitduran 2020-07-12 19:27:53 UTC
Created attachment 162934 [details]
the missing image

the missing image.
Comment 4 mucahitduran 2020-07-12 19:31:01 UTC
Created attachment 162935 [details]
original .odt file
Comment 5 mucahitduran 2020-07-12 19:32:57 UTC
(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.
Comment 6 Telesto 2020-07-12 21:33:43 UTC
(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..
Comment 7 Telesto 2020-07-13 08:36:55 UTC
File contains a multitude of problems :-( Created a few separate reports for them.  Not sure if found all problems already
Comment 8 Telesto 2020-07-13 08:41:16 UTC
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
Comment 9 Telesto 2020-07-13 09:51:38 UTC
This and bug 134773 are likely the same thing
Comment 10 Terrence Enger 2020-08-01 01:19:31 UTC
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.
Comment 11 Telesto 2020-08-01 08:26:22 UTC
Adding CC: to Michael Stahl
Comment 12 Timur 2020-08-01 09:36:04 UTC
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.
Comment 13 Telesto 2020-08-01 18:20:41 UTC
(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
Comment 14 Commit Notification 2020-08-14 14:57:43 UTC
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.
Comment 15 Michael Stahl (CIB) 2020-08-14 15:01:21 UTC
hope i fixed it on master
Comment 16 Commit Notification 2020-08-17 08:35:02 UTC
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.
Comment 17 Commit Notification 2020-08-17 08:36:17 UTC
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.
Comment 18 Terrence Enger 2020-08-18 15:10:49 UTC
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.
Comment 19 Telesto 2020-08-18 19:48:16 UTC
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
Comment 20 Telesto 2020-08-18 20:49:10 UTC
(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.
Comment 21 Terrence Enger 2020-08-18 23:22:57 UTC
(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.