This is some kind of follow-up to bug 43869 - “Paste special as RTF inserted at wrong position, undo stack damaged”. I wanted to verify that bug 43869 is completely fixed, without any unwanted side-effects. However, when I repeat Rainer’s steps from https://bugs.freedesktop.org/show_bug.cgi?id=43869#c2 with the current 4.0.0beta1 [1], I still do not get not what one would expect: > 1. Start LibO > > Start Center appears > 2. Open new Calc document with click on "New Spreadsheet" > 3. fill 'A1:A5' with "a" > 4. Select / Highlicht A1:A5 > 5. <control+c> for Copy > 6. Menu 'File -> New -> WRITER document' > 7. Click into new Writer document, type 5 times <enter>, then "xxx" > 8. 2 times <arrowup> > 9. Long click on "Paste" toolbar icon > 10. select "As RTF' > Expected: 5 rows "a" inserted > Actual: "xxx" deleted as reported, some things else (very quick) I still see a problem: *nothing* is pasted (no “5 rows ‘a’ inserted). Of course, this is a big progress as compared to bug 43869 -- the “xxx” are not deleted, the page format is not changed, and the undo stack is not damaged. But pasting “As RTF” still does not work ... Of course, this is very probably a different bug, therefore I have opened this new bug report (instead of opening bug 43869 again). Tests done on Mac OS X 10.6.8 (Intel). [1] Full version information: LOdev 4.0.0.0.beta1 (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7) TinderBox: MacOSX TDF Release, Branch:libreoffice-4-0, Time: 2012-12-05_22:13:37 I have installed the German langpack for that version. *No* extensions installed (only the bundled ones).
Confirmed, the pasted cells are flashing for a moment, then they're gone.
@ Urmas: Thank you for confirming this issue! @ Miklós Vajna: Hi Miklós, can you please take a look at this issue? It seems that bug 43869 - “Paste special as RTF inserted at wrong position, undo stack damaged” - is still not solved completely; this is a remainig issue. Thank you very much!
Still [Reproducible] with parallel installation of "LOdev 4.0.0.0.beta2 - GERMAN UI / German Locale [Build ID: 4104d660979c57e1160b5135634f732918460a0)]" {tinderbox: @6, pull time 2012-12-20} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch Especially Urmas' observation seems interesting, and I can confirm it (better reproducible with Filled Cells until G300). I am pretty sure that the problem is in Writer LibO 4. Copy from Calc 4.0 to Writer 3.6.4 works without problems, but Copy from Calc 3.6.4 to Writer 4.0 shows the problem
It seems to be some real UNDO, I checked the "contents.xml. From 3.6.4, it contains lots or characteristic ">a<" and has size 330kB, from 4.0 those characteristic ">a<" are missing and size is only 4 KB. Component Writer due to results in comment before. Already [Reproducible] with unzipped installation of "LOdev 4.0.0.0.alpha1+ - ENGLISH UI / German Locale [Build ID: 76c921de48ee41716b5a500b892945c704da73c)]" {tinderbox: Win-x86@6, pull time 2012-12-10 09:43:47} on German WIN7 Home Premium (64bit) with own separate User Profile Still worked fine with * server-installation of Master "3.7.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: b255de8]" (tinderbox: Win-x86@6-fast, pull time 2012-06-05 23:16:58)
In the bibisect40 repository, both latest and oldest shows the bug. However, with Rainer's comment about 3.7.0alpha0+ working, I was able to find commit 20bcb05, which correctly shows (and keeps!) the pasted cells. Bisecting from there, I get f53a1835f8b1fefbaf0d4dd8e9eaa4232bb246af is the first bad commit commit f53a1835f8b1fefbaf0d4dd8e9eaa4232bb246af Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 08:58:33 2012 +0000 source-hash-4026e1824de8ff9b5d006ae6eba491f91bc4e599 commit 4026e1824de8ff9b5d006ae6eba491f91bc4e599 Author: Markus Mohrhard <markus.mohrhard@googlemail.com> AuthorDate: Fri Nov 30 22:19:45 2012 +0100 Commit: Markus Mohrhard <markus.mohrhard@googlemail.com> CommitDate: Fri Nov 30 22:19:45 2012 +0100 prevent uncloseable cond format dlg :100644 100644 0148732ba831d13d60eb2213d1794f16b7029e0a d6a3e35f1dc57a7469408bdb1aaa587ba6cf3cfe M ccache.log :100644 100644 faaf82f3923c59ad645a961b233713d5d179a048 a2d3790ddaa245f4d56968133ce5be440af2c033 M commitmsg :100644 100644 023925d82f87428b3183f761b7319ac1fef77181 3fad2a60908b6b6bc1de0af560f7239a89b54e73 M dev-install.log :100644 100644 bb4428865c51a8860f5dd6c10048b3e7374064d2 2df1def8f8a08f16f92540ae4eab28de4984a88f M make.log :040000 040000 795c42648aad6b4ea86bba761685294fa8e11fd2 0dc3db85f8784d986d2364a0972044d502c2a5e3 M opt and `git bisect log` shows # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [20bcb05266724b495f909e6bdc5b253b15515e7d] source-hash-f260c656da4457c5d87c161bdd43ad3023d07472 git bisect start 'latest' '20bcb05' # good: [915b1e16f20d5ce2a32f911ef051103455600845] source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74 git bisect good 915b1e16f20d5ce2a32f911ef051103455600845 # good: [79f6cca2cef3c5a9cbda4089d46146ff3099648b] source-hash-11e776023c89b3de690b37ffaed18ec996b9c207 git bisect good 79f6cca2cef3c5a9cbda4089d46146ff3099648b # bad: [f53a1835f8b1fefbaf0d4dd8e9eaa4232bb246af] source-hash-4026e1824de8ff9b5d006ae6eba491f91bc4e599 git bisect bad f53a1835f8b1fefbaf0d4dd8e9eaa4232bb246af # good: [5655f1571312ca27537c9c147c69d6431986b76d] source-hash-b67a51b40a4876f4bd97a2917103112006710b0c git bisect good 5655f1571312ca27537c9c147c69d6431986b76d # good: [8407d6926d9fa83ebbd8e03de319ea63df131753] source-hash-3d4288c1c0b593421c7f6619c88584bdb7c53337 git bisect good 8407d6926d9fa83ebbd8e03de319ea63df131753 Just for the fun of it, I am bisected from the other end, giving the words 'good' and 'bad' the opposite meanings. (I am sure there is some deep philosophical point to be made here, but I am not smart enough to figure it out <grin />.) This gives f98bc0bdf78118131e63c79dbc96707c8d9e5020 is the first bad commit commit f98bc0bdf78118131e63c79dbc96707c8d9e5020 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Apr 25 07:28:24 2012 +0200 source-hash-ce97851773a06103504972eb2771eecd7dd81e36 commit ce97851773a06103504972eb2771eecd7dd81e36 Author: David Tardon <dtardon@redhat.com> AuthorDate: Mon Feb 6 19:12:02 2012 +0100 Commit: David Tardon <dtardon@redhat.com> CommitDate: Mon Feb 6 19:12:02 2012 +0100 fix typo :100644 100644 e1c1d62aa980fee004430f920cdbe3fd1ce79bf0 9acf11b8f6f5e26b03649767813ac42f72c38e1b M autogen.log :100644 100644 c14237a7b6ebde67a83585c9b057c78710e08ea2 db4232175b715b6c7f322b17041f56a9145e1622 M ccache.log :100644 100644 c407d12366338584cbcebf2197cd7fcdcf1c522b 1b83a94159f8aa22e004b5dc2ebe1895b32a2724 M commitmsg :100644 100644 3be616510b5296b5ae2f5c154a6c51f7ba49bf24 cc9f341a09ba536bb41d4219c5b7f5dd219d7cc6 M dev-install.log :100644 100644 637e789a93608b99c13fec9e598c2e7a4c454c6d 08ab33c46c34b7b9b0f8b7f21161ad1c1a2ed59a M make.log :040000 040000 c47ba9e6977c3c8a957b11ec3f8b85cfa50362af f87831ea583aaccb888e681ce264cc1e4e44d3aa M opt and # bad: [20bcb05266724b495f909e6bdc5b253b15515e7d] source-hash-f260c656da4457c5d87c161bdd43ad3023d07472 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start '20bcb05' 'oldest' # bad: [06a6822e92ee6461d42b4bea6e4b4dfbb813c483] source-hash-3b328186706e6819acfea7b3a6dc8c9d3b6f9693 git bisect bad 06a6822e92ee6461d42b4bea6e4b4dfbb813c483 # bad: [f98bc0bdf78118131e63c79dbc96707c8d9e5020] source-hash-ce97851773a06103504972eb2771eecd7dd81e36 git bisect bad f98bc0bdf78118131e63c79dbc96707c8d9e5020 # good: [e967495ca3b2f401214391732de1795beb02a273] source-hash-6598e65cfcabd270199d09d11d9d93639bca620d git bisect good e967495ca3b2f401214391732de1795beb02a273 # good: [c7ce6bbce360248b617179207a88e93f5bb533b2] source-hash-f82da782158d8f5b89a6a9057df1a4695425ed75 git bisect good c7ce6bbce360248b617179207a88e93f5bb533b2 # good: [292d168e233214c33a2b18f43f6cf23c27d98e1b] source-hash-b95bb2da9a197f950a2f40715ad731296cdb5296 git bisect good 292d168e233214c33a2b18f43f6cf23c27d98e1b # good: [0f6d5d5e1e8ff2ca0f2f6d43ae7d1f80d6dc29f1] source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670 git bisect good 0f6d5d5e1e8ff2ca0f2f6d43ae7d1f80d6dc29f1 # good: [a8e6c8ab0acf74c0b3ede21427f37e55c3a48727] source-hash-f176c9ba7be7f3051a52b9f57b56124038c0cfd6 git bisect good a8e6c8ab0acf74c0b3ede21427f37e55c3a48727 # good: [4d2e7c1f9a87c0ee56840ce9460a8a0fc652d911] source-hash-43c7830b03d141ae11d8617c0fdabefa32dd243c git bisect good 4d2e7c1f9a87c0ee56840ce9460a8a0fc652d911 And then, here come attachments of valgrind of version ce97851 (keeps the pasted a's) and version 43c7830 (wipes away the pasted a's). It is ironic that the version keeping the a's has more valgrind warnings, but I *think* I have written this the right way around. HTH, Terry.
Created attachment 72393 [details] valgrind keeping pasted cells
Created attachment 72394 [details] valgrind losing pasted cells
@ Markus Mohrhardt, @ David Tardon: First, let me whish you (a little late, of course ;-) a Happy New Year! If I understand Terrence Enger’s bibisecting results correctly, this bug seems to have been introduced around two commits by you -- see comment #5 here. Could you please take a look at this issue and check if the bug could be an unwanted side effect of the one or the other of these commits? Thank you very much in advance!
(In reply to comment #8) > @ Markus Mohrhardt, > @ David Tardon: > Miklos is the guy to ask when it comes to RTF.
> Miklos is the guy to ask when it comes to RTF. I know. But is this really only a RTF problem? At the first glance, it looks so, but at the second one at least a simple-minded bug wrangler like me begins to feel doubtful; especially because of Terrence Enger’s bibisect results. So, instead of just referring us to Miklós, what about helping him a little bit in fixing this issue? ;-) e.g. just by making sure that no one of the two commits mentioned in Terrence Enger’s bibisect results has any influence on this issue ...
It is entirely possible that I misunderstand something--indeed, I hope I do--but ... $ git log --pretty=oneline 43c7830..ce97851 | wc 2450 17658 209314 I think this means that that there were 2450 commits between the two that I found through bibisect. So, bibisect spreads suspicion far beyond the two commits cited. Correction or guidance welcome. Terry.
This is probably caused by my ed654c4aa7f9f10fcb16127349009bc0c38b12e8, yes -- and has little to do with Calc. Please confirm that this worked fine on 3.6, then it can be tagged as a regression.
(In reply to comment #12) > This is probably caused by my ed654c4aa7f9f10fcb16127349009bc0c38b12e8, yes > -- and has little to do with Calc. Ah, OK -- so I have missunderstood the bibisect results. So, sorry for disturbing you, Markus and David; I will be more careful the next time. > Please confirm that this worked fine on 3.6, then it can be tagged > as a regression. It works correctly for me with LibreOffice 3.6.4.3 (Build ID: 2ef5aff) on Mac OS X 10.6.8 (Intel); so this is indeed a regression. Tagging it as such.
Because Terrence Enger already bibisect it -> whiteboard status to 'bibisected40'
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e521930ea1c855c236efb67793e540d07c201d35 fdo#58327: writerfilter: RemoveLastParagraph is tricky: 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=db67dad3065e3578f1321822ffb63eef83fe5377&h=libreoffice-4-0 fdo#58327: writerfilter: RemoveLastParagraph is tricky: It will be available in LibreOffice 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.
Resolved in master and -4-0.
*** Bug 59676 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (filter:rtf) Replace rtf_filter -> filter:rtf. [NinjaEdit]