Bug 108612 - FORMATTING Comment boxes: dimensions and position lost at copy
Summary: FORMATTING Comment boxes: dimensions and position lost at copy
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.3.2 release
Hardware: All All
: medium minor
Assignee: Eike Rathke
URL:
Whiteboard: target:6.0.0 target:5.4.1 target:5.3....
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Calc-Comments
  Show dependency treegraph
 
Reported: 2017-06-18 10:52 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2017-08-01 03:25 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
zip-File with 2 spreadsheets to reproduce resp. demonstrate the error (18.24 KB, application/x-zip-compressed)
2017-06-18 10:52 UTC, Stefan_Lange_KA@T-Online.de
Details
Screenshots of tests with LO 6.0 in Win10 and with LO 5.3.3 in Ubuntu (623.75 KB, application/gzip)
2017-06-27 18:40 UTC, Stefan_Lange_KA@T-Online.de
Details
Valgrind log from master (56.35 KB, text/plain)
2017-07-03 17:49 UTC, Buovjaga
Details
Valgrind log from master, A10 as the source of copying (56.35 KB, text/plain)
2017-07-03 18:03 UTC, Buovjaga
Details
Log of terminal and gdb from the test (18.53 KB, application/vnd.oasis.opendocument.text)
2017-07-05 22:35 UTC, Stefan_Lange_KA@T-Online.de
Details
Log of terminal from install libreoffice-dbg (2.55 KB, text/plain)
2017-07-06 08:20 UTC, Stefan_Lange_KA@T-Online.de
Details
Screenshot from my test (152.03 KB, image/jpeg)
2017-07-08 09:19 UTC, Stefan_Lange_KA@T-Online.de
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan_Lange_KA@T-Online.de 2017-06-18 10:52:31 UTC
Created attachment 134102 [details]
zip-File with 2 spreadsheets to reproduce resp. demonstrate the error

When cells with comment are copied via copy + paste, only the comment box of first copied cell is pasted with correct position and dimension.
From the second time on dimensions and position of comment boxes are lost at copy + paste.

Reproducing the the error:

- open file "Test_Comment_V2.ods" from the attached zip file

- copy cell A4 into the clipboard
- paste it into cell E4 (and into cell I4 etc.)
-> Result: comment boxes are pasted with correct position and dimensions

- copy cell A10 (or cell A4 a second time) into the clipboard
- paste it into cell E10 (and into cell I10 etc.)
-> Result: comment boxes are pasted with wrong position and dimensions

(see file "Test_Comment_V2_edited.ods" in the zip-file)

Error reproduced also with Version: 5.3.4.2 (x64) and with 
Version: 6.0.0.0.alpha0+ (x64)
Build ID: d6c4c576ef71f2294ec8eefc6576a797220e6809
CPU threads: 2; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-06-18_00:32:25
Locale: de-DE (de_DE); Calc: group
Comment 1 Buovjaga 2017-06-27 12:02:43 UTC
I got different results: I got the wrong position after pasting to I*. When I copied A10, it "reset" and only paste to I10 was wrong.

Yet: no problems at all in 3.6.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha0+
Build ID: f808c50c6eece87d515df3b84b1c774395b5d9bc
CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on June 26th 2017

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)
Comment 2 raal 2017-06-27 15:50:02 UTC
no repro. Version: 6.0.0.0.alpha0+
Build ID: 643da8ec4e721d33dfdf8d78bedd50a915f1188d
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-06-26_01:29:47
Comment 3 Stefan_Lange_KA@T-Online.de 2017-06-27 18:40:30 UTC
Created attachment 134320 [details]
Screenshots of tests with LO 6.0 in Win10 and with LO 5.3.3 in Ubuntu

Maybe the bug exists only in Windows. I can reproduce the bug with the (nearly) newest builds of LO 6.0 in Win 10 (build 15063.413 64 bit, preview build 16226 32 bit and 64 bit), but not with LO 5.3.3 in Ubuntu, see screenshots in attached archive file "Screenshots_Bug_108612.tar.gz"!
Comment 4 Buovjaga 2017-06-28 10:20:21 UTC
(In reply to Stefan_Lange_KA@T-Online.de from comment #3)
> Created attachment 134320 [details]
> Screenshots of tests with LO 6.0 in Win10 and with LO 5.3.3 in Ubuntu
> 
> Maybe the bug exists only in Windows. I can reproduce the bug with the
> (nearly) newest builds of LO 6.0 in Win 10 (build 15063.413 64 bit, preview
> build 16226 32 bit and 64 bit), but not with LO 5.3.3 in Ubuntu, see
> screenshots in attached archive file "Screenshots_Bug_108612.tar.gz"!

No, as I said in my comment 1 I am seeing the problem on Linux, but only with slightly different results/steps.
Comment 5 raal 2017-07-02 21:17:19 UTC
This seems to have begun at the below commit.
Adding Cc: to Eike Rathke; Could you possibly take a look at this one? Thanks


a3a754ba53116b1ed03ad493908db89e1d636451 is the first bad commit
commit a3a754ba53116b1ed03ad493908db89e1d636451
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Fri Feb 10 22:00:08 2017 -0800

    source sha:cb566c056b0e8f9f73dac3cbaf497e102a247cb9

	author	Eike Rathke <erack@redhat.com>	2017-01-18 15:18:38 (GMT)
committer	Eike Rathke <erack@redhat.com>	2017-01-18 15:19:09 (GMT)
commit	cb566c056b0e8f9f73dac3cbaf497e102a247cb9 (patch)
tree	93ba07dd11cab7ef22778971959de3bc7694ee1d
parent	2fb220093f7178f75ebd582bbcd956c1ee7e03db (diff)
tdf#104967 prevent crash when pasting notes originating from a closed document
This is only a workaround to prevent a crash, the actual note content is lost
when pasting, only a standard empty note caption will be pasted.
Comment 6 Eike Rathke 2017-07-03 12:18:53 UTC
(In reply to raal from comment #5)
> This seems to have begun at the below commit.
I doubt that. That code is executed only when closing a document that is the clipboard source to forget the caption pointers pointing into that document's drawing layer. The bug description doesn't involve closing the document.
Comment 7 Eike Rathke 2017-07-03 12:53:58 UTC
Fwiw, I can not reproduce (on Linux) in any version, 5.3.3, 5.3.4, >=5.4.0.beta2 or master.
Comment 8 Buovjaga 2017-07-03 17:49:17 UTC
Created attachment 134462 [details]
Valgrind log from master

This is a log of copying A4 and pasting to E4 and then to I4.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha0+
Build ID: 98befbb26217b0bf3f35354e418a355280c52cfc
CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on June 29th 2017
Comment 9 Eike Rathke 2017-07-03 17:56:33 UTC
Does the log for copying A10 and pasting to E10, I10 differ in anything relevant for this case?
Comment 10 Buovjaga 2017-07-03 18:03:09 UTC
Created attachment 134465 [details]
Valgrind log from master, A10 as the source of copying
Comment 11 Eike Rathke 2017-07-03 18:35:02 UTC
Nothing suspicious so far. With the commit Raal identified and a screenshot he sent me, I suspect that under some unknown circumstances ScDocument::IsClipboardSource() returns true when it should not (which is the only possibility where the identified commit comes into play). There is one step in the reproduction scenario, copying A10 to the clipboard when A4 was already copied, where the first clipboard document is destroyed and ScDocument::IsClipboardSource() is called.

Now, if someone who can reproduce the bug and has debug capabilities could set a breakpoint in sc/source/core/data/documen2.cxx ScDocument::~ScDocument() on the call to IsClipboardSource(), then after having copied A4 already when copying A10 into the clipboard the breakpoint should be hit. Stepping into IsClipboardSource() it should not return true, but if it does it would be good to know why and what made it think it should..
Comment 12 Eike Rathke 2017-07-03 18:49:27 UTC
Further thinking: if so that probably would involve that ScModule::GetClipDoc() returns a document that is not the actual clipboard document but an ordinary one, most likely the source document itself, which would be even weirder..
Comment 13 Buovjaga 2017-07-04 17:41:51 UTC
Ok, I launched LibO and then in a terminal

sudo gdb --pid `pgrep soffice`

I let it attach and then in the (gdb) prompt gave

break documen2.cxx:385

ie. this line: https://cgit.freedesktop.org/libreoffice/core/tree/sc/source/core/data/documen2.cxx#n385

Then I gave c to continue. The breakpoint is hit the first time already when I pasted A4 to E4. I continued and this is what I got when copying A10:

Thread 1 "soffice.bin" hit Breakpoint 1, ScDocument::~ScDocument (this=0x6a45170, 
    __in_chrg=<optimized out>) at /home/user/libreoffice/sc/source/core/data/documen2.cxx:385
385         if (IsClipboardSource())
(gdb) step
ScDocument::IsClipboardSource (this=this@entry=0x6a45170)
    at /home/user/libreoffice/sc/source/core/data/document.cxx:2544
2544    {

It was a bit disturbing along the way that gdb grabbed my mouse click focus. I managed to solve it with this: https://unix.stackexchange.com/a/40472
Comment 14 Buovjaga 2017-07-04 18:43:48 UTC
I checked with Áron and he asked me to use next instead of step. This is with copying A10 while A4 is already in the clipboard:

385         if (IsClipboardSource())
(gdb) n
397         mxFormulaParserPool.reset();
(gdb) n
400         pExternalRefMgr.reset();
(gdb) n
402         ScAddInAsync::RemoveDocument( this );

So I understand the if is evaluated to false.
Comment 15 Buovjaga 2017-07-05 16:19:06 UTC
Stefan: if you would like to try what result you get (as I had different symptoms):

Install gdb
Launch LibreOffice from the commandline with
SAL_NO_MOUSEGRABS=1 ./soffice
That way your mouse clicks will not be hijacked.

Then attach gdb to LibreOffice:
sudo gdb --pid `pgrep soffice`

Press enter when it asks. When you see the (gdb) prompt, give the command
break documen2.cxx:385

Then give the command: c

Then start doing the reproduction steps in LibreOffice. Use c in gdb to continue until before you have copied A10 to clipboard. When it breaks the next time, give the command n (for next) like in my previous comment. Then you can show us your results.
Comment 16 Stefan_Lange_KA@T-Online.de 2017-07-05 22:35:38 UTC
Created attachment 134505 [details]
Log of terminal and gdb from the test

Buovjaga, I have tried to make what you have written, but I had some problems, see also attached log in the odt document!

First problem is:
(gdb) break documen2.cxx:385
No source file named documen2.cxx.
Make breakpoint pending on future shared library load? (y or [n]) y

Must be available for the test the source documen2.cxx:385? When yes, where must it be located? 
  
Second problem: In the test didn't come a break, not at first copy + paste and not at second. I don't know if the reason is the missing (or wrongly located) source or is it the fact that I can't reproduce the error in Linuy (Ubuntu 17.04) - see my Comment 3.

PS: I am a beginner in Ubuntu and I'm not very familiar with this system.
Comment 17 Buovjaga 2017-07-06 07:16:34 UTC
Ok, you could first install the debug package:
sudo apt-get install libreoffice-dbg

Note that it is over 2,5 gigabytes.
Comment 18 Stefan_Lange_KA@T-Online.de 2017-07-06 08:20:13 UTC
Created attachment 134511 [details]
Log of terminal from install libreoffice-dbg

I couldn't install libreoffice-dbg because of errors, see attached log. Maybe version conflicts?
Comment 19 Eike Rathke 2017-07-06 10:48:26 UTC
(In reply to Stefan_Lange_KA@T-Online.de from comment #18)
> I couldn't install libreoffice-dbg because of errors, see attached log.
> Maybe version conflicts?
Your system pulls in a way too old libreoffice-dbg version 4.2.8, make sure your dbg package repository matches the release of your regular package repository, or wherever you installed LO 5.3.3 from.
Comment 20 Eike Rathke 2017-07-06 10:49:32 UTC
(In reply to Buovjaga from comment #15)
> Then attach gdb to LibreOffice:
> sudo gdb --pid `pgrep soffice`
Don't use sudo ...
Comment 21 Buovjaga 2017-07-06 11:23:36 UTC
(In reply to Eike Rathke from comment #20)
> (In reply to Buovjaga from comment #15)
> > Then attach gdb to LibreOffice:
> > sudo gdb --pid `pgrep soffice`
> Don't use sudo ...

I have to personally. If I don't, it says:
ptrace: Operation not permitted.

This is because of https://wiki.archlinux.org/index.php/security#ptrace_scope
Comment 22 Eike Rathke 2017-07-06 14:59:00 UTC
So the debugger then can wipe the entire system, great security feature ;-)
SCNR.
Comment 23 Commit Notification 2017-07-06 15:08:00 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d5020f35aec54f0241fa58557dc6caadc149f5a9

Attempt to blind fix tdf#108612 explicitly checking for clipboard document

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.
Comment 24 Eike Rathke 2017-07-06 15:11:47 UTC
If someone who could originally reproduce could please check with one of the next master builds that includes the above commit if that fixes the problem? Thanks.
Comment 25 Commit Notification 2017-07-06 15:27:43 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=432f766892478f4693ca830e7d07bd195637fae0

Assert that GetClipDoc() is indeed a clipboard document, tdf#108612 related

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.
Comment 26 Stefan_Lange_KA@T-Online.de 2017-07-08 09:19:28 UTC
Created attachment 134545 [details]
Screenshot from my test

The error still occurs with
Version: 6.0.0.0.alpha0+ (x64)
Build ID: 7b4f4f15971047664fa278fff96b959d53b272b3
CPU threads: 2; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-07-08_01:39:24
Locale: de-DE (de_DE); Calc: group
Comment 27 Buovjaga 2017-07-09 18:42:05 UTC
Yep, I am still seeing my own variation of the issue.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha0+
Build ID: b91cb7d137b5d8fd203bbdc1c4e3d0e851fd5aa6
CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on July 9th 2017
Comment 28 Aron Budea 2017-07-10 01:38:56 UTC
I can repro this as well (build from 07-07), and can debug into the mentioned code, but I'm not sure what I should be looking for.
Is there a way to identify what ScModule::GetClipDoc() returns? I can see that aDocName is "Test_Comment_V2". bIsClip is true, so it passes the assert.
Comment 29 Eike Rathke 2017-07-10 12:27:37 UTC
(In reply to Aron Budea from comment #28)
> I can see
> that aDocName is "Test_Comment_V2". bIsClip is true, so it passes the assert.
You mean at the pDoc within ScModule::GetClipDoc()? On whic platform? When? On the first copy? Or the second copy? The weird thing is that on Linux the ScTransferObj::GetOwnClipboard() already returns nullptr for me so there's never a clipboard doc in this scenario until the original is closed after something was copied to the clipboard.
Comment 30 Aron Budea 2017-07-10 13:09:56 UTC
(In reply to Eike Rathke from comment #29)
> You mean at the pDoc within ScModule::GetClipDoc()? On whic platform? When?
> On the first copy? Or the second copy? The weird thing is that on Linux the
> ScTransferObj::GetOwnClipboard() already returns nullptr for me so there's
> never a clipboard doc in this scenario until the original is closed after
> something was copied to the clipboard.

Yes. On Windows 7, during second copy.
Would the normal behavior be to return nullptr as it happens for you on Linux?
Comment 31 Eike Rathke 2017-07-17 13:02:10 UTC
Hard to say, the current ScTransferObj should had been released already, but it is a weak reference and maybe things differ in detail. However, what actually is important that the only ScDocument destroyed is the then current clipboard document when copying the second cell. The ScDocument::IsClipboardSource() called from there must return false.

Could you do me a favour and check if there in ScDocument::IsClipboardSource() pClipDoc==this and/or both, pClipDoc->bIsClip and this->bIsClip are true?
Comment 32 Aron Budea 2017-07-17 20:39:00 UTC
(In reply to Eike Rathke from comment #31)
> Hard to say, the current ScTransferObj should had been released already, but
> it is a weak reference and maybe things differ in detail. However, what
> actually is important that the only ScDocument destroyed is the then current
> clipboard document when copying the second cell. The
> ScDocument::IsClipboardSource() called from there must return false.
> 
> Could you do me a favour and check if there in
> ScDocument::IsClipboardSource() pClipDoc==this and/or both,
> pClipDoc->bIsClip and this->bIsClip are true?

During second copy to clipboard, right?

1. pClipDoc and this are different.
2. pClipDoc->bIsClip is true,
   this->bIsClip is also true.
Comment 33 Eike Rathke 2017-07-19 19:54:23 UTC
(In reply to Aron Budea from comment #32)
> During second copy to clipboard, right?
Correct.

> 1. pClipDoc and this are different.
> 2. pClipDoc->bIsClip is true,
>    this->bIsClip is also true.

That's completely odd, but confirms my suspicion.
Thanks.
Comment 34 Commit Notification 2017-07-20 08:20:03 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=52e09f2c03f7cc024b2973c4806283c324fc23df

Another attempt to blind fix tdf#108612

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.
Comment 35 Eike Rathke 2017-07-20 08:24:04 UTC
Hopefully that will do..
If you could please check with one of the next master builds that includes the above commit if that fixes the problem? Thanks.
Comment 36 Buovjaga 2017-07-20 12:31:20 UTC
(In reply to Eike Rathke from comment #35)
> Hopefully that will do..
> If you could please check with one of the next master builds that includes
> the above commit if that fixes the problem? Thanks.

I confirm that "my version" of the problem is gone!

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha0+
Build ID: 8d4d1e8d1cd4b400bc395dcbb98fb1e82eaf4e0f
CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on July 20th 2017
Comment 37 Eike Rathke 2017-07-20 19:55:44 UTC
Great, Thanks!

Pending review
https://gerrit.libreoffice.org/40249 for 5-4
https://gerrit.libreoffice.org/40251 for 5-3
https://gerrit.libreoffice.org/40250 for 5-4-0
https://gerrit.libreoffice.org/40252 for 5-3-5
Comment 38 Eike Rathke 2017-07-20 20:02:29 UTC
Btw, do people who could reproduce this also run some "clipboard enhancer", multiple clipboard manager or such thing?
Comment 39 Aron Budea 2017-07-20 21:44:17 UTC
(In reply to Eike Rathke from comment #38)
> Btw, do people who could reproduce this also run some "clipboard enhancer",
> multiple clipboard manager or such thing?

Looks fixed here as well, and no, I'm not using any kind of clipboard manager.
Comment 40 Commit Notification 2017-07-21 04:14:16 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c4b67ac73aae4f44938c296d1a54ff68c6e2ae8&h=libreoffice-5-4

Blind fix tdf#108612 explicitly checking for and against clipboard document

It will be available in 5.4.1.

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.
Comment 41 Commit Notification 2017-07-21 04:15:37 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5917736e39ff1e5d6995f93e9108082a87d9e35&h=libreoffice-5-3

Blind fix tdf#108612 explicitly checking for and against clipboard document

It will be available in 5.3.6.

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.
Comment 42 Stefan_Lange_KA@T-Online.de 2017-07-21 06:50:10 UTC
Test was OK with

Version: 6.0.0.0.alpha0+
Build ID: a9588baca8137f51e2ca72e40b1f448b0e1885d1
CPU threads: 1; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-07-21_02:58:26
Locale: de-DE (de_DE); Calc: group

and with

Version: 6.0.0.0.alpha0+ (x64)
Build ID: a9588baca8137f51e2ca72e40b1f448b0e1885d1
CPU threads: 2; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-07-21_04:09:11
Locale: de-DE (de_DE); Calc: group

I have also made a test with activated "Cipboarder" (Multi clipboard manager from "8GadgetPack" for Windows 8):
When cells are copied directly via copy + paste, they are pasted correctly, but when the are selected for paste in "Cliboarder", only cell contents is - not correctly - pasted. Seems that in "Clipboarder" are saved for paste not all attributes of Calc cells.
Comment 43 Commit Notification 2017-07-21 09:39:05 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-5-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5fb6e24496a925eafe91b337ab4e8ae6a4ed8900&h=libreoffice-5-4-0

Blind fix tdf#108612 explicitly checking for and against clipboard document

It will be available in 5.4.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.
Comment 44 Commit Notification 2017-07-30 19:30:37 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-5-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=54db051a7224f053502d5be14ba512837d11b70e&h=libreoffice-5-3-5

Blind fix tdf#108612 explicitly checking for and against clipboard document

It will be available in 5.3.5.

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.
Comment 45 Stefan_Lange_KA@T-Online.de 2017-07-31 21:37:18 UTC
Test with
Version: 5.3.5.2 (x64)
Build-ID: 50d9bf2b0a79cdb85a3814b592608037a682059d
CPU-Threads: 4; Betriebssystem:Windows 6.19; UI-Render: GL; Layout Engine: new; 
Gebietsschema: de-DE (de_DE); Calc: CL
was OK!
Comment 46 Aron Budea 2017-08-01 03:25:11 UTC
Great, let's set to verified, then.