- new spreadsheet - data in few cells > Select > Copy - new text document - 5 empty paragraphs - type xxx in 6th paragraph - go to 2nd paragraph - Ctrl-V > pasted as Calc object - go to 4nd paragraph - Ctrl-SHft-V - Paste as text only > pasted correctly Ctrl-SHft-V - Paste as rtf > nothing is pasted, last paragraph with xxx is removed
seen in master builds before. IIRC also had some correspondence about this on a list? Cannot remember exactly ;-)
[Reproducible] with Parallel Dev-Installation of "LibreOffice 3.5.0 Beta1 - WIN7 Home Premium (64bit) German UI [Build-ID: 7362ca8-b5a8e65-af86909-d471f98-61464c4] Windows_Release_Configuration 11-Dec-2011 06:51" Most of reporter's steps are not required, so here more simple description 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) Further investigation will show that Paper size will be modified (for me: A4 to Letter) and also page margins. It seems that for a very short moment a table will be inserted. Not a particular Beta bug, I also see that in Master from beginning of December.
Onla pasting as RTF with single cell A1 in clipboard will paste the "a" at the end. Might be related to "Bug 43882 - EDITING: CRASH when undo copy paste" @Cédric: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Also reproducible with other Master builds from November and September. Works fine with Server installation of Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]"
*** Bug 43480 has been marked as a duplicate of this bug. ***
<https://bugs.freedesktop.org/show_bug.cgi?id=43480#c4> and comments before show that there exist additional strange effects, proved for RTF until now, others possible. So I modify Summary. Proceeding as per Bug 43480#c4 and then clicking undo icon also shows an undo stack problem (pasted text remains).
[Reproducible] also on MacOS X 10.6.8 with the steps given in Comment #2 and LibreOffice 3.5.0 beta 1 Build-ID: 1ce7995-7f15fca-1f1fd1a-ca8e46d-5bcbce4 Build Date: 2011-12-13 Installation File name: libreoffice-3-5~2011-12-13_04.48.06_LibO-Dev_3.5.0beta1_MacOS_x86_install_en-US. Everything happens like in the description given by Rainer Bielefeld in Comment #2, including the change of the paper size.
*** Bug 44199 has been marked as a duplicate of this bug. ***
*** Bug 44862 has been marked as a duplicate of this bug. ***
That seems to be related to the new RTF import filter. Even shorter steps to reproduce: 1) Open writer, enter "aaa", then an empty paragraph, finally "bbb". 2) Select "aaa", navigate to the empty paragraph, select paste special -> RTF. Bugs: 1) The new "aaa" is inserted at the end of the doc. 2) If you keep pressing ctrl-z, "bbb" will be removed before the second "aaa". The problem is probably somewhere in SwRTFReader::Read(). I'll try to have a look soon.
We discussed this with Cédric and the conclusion is that it's better to just revert back to the old RTF filter for pasting, since the undo + position handling via uno in writerfilter (where the new filter is) won't be a small patch. ;) Fixed in master: http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb147bbb801b53dba8928340df7e2aa2d4545349 Will request a cherry-pick to -3-5 (and maybe -3-5-0).
*** Bug 45248 has been marked as a duplicate of this bug. ***
Fixed in -3-5: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=85fb62b9103428ee83e5b9f9ef7bdcb736e04ff9
And finally fixed in -3-5-0: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5-0&id=20196b4e7c7de25c1863e7919d205d0352616c56
note that Insert->File is also affected; if you insert a DOCX file it'll be at the end, not at the cursor position (but apparently the undo stack is cleared then). have looked a bit at the problem, and while shoving an insert position SwXTextRange into writerfilter sounds easy enough, the problem is that currently the domain mapper uses various XText*Append interfaces to insert the actual content, and those don't accept an insert position parameter, they always append at the end. in contrast, xmloff uses the older XText interface, which does take an insert position, and thus does not suffer from this problem. it is currently a mystery to me why these XText*Append interfaces were introduced. thus i agree that falling back to the old RTF filter is the best now.
This issue was present on the build 3.5 RC 1 and RC 2. But apparently is no longer in nightly build LOdev 3.5.1rc0+ Build ID: 5de902f-8c0b455-f9b8d0b-2d9b003-24eb504. Thank you. PS: And I guess Bug 45312 is a duplicate of this. ;)
*** Bug 45312 has been marked as a duplicate of this bug. ***
It's definitely in 3.5.1.1.
[Reproducible] with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) Works fine with LOdev 3.6.0alpha0+ Build ID: 9518535-d09cf17-8a74106-c695ecd-16afab (same OS May be some mishap with backporting? Or new problem? @Urmas: What's your OS? Miklós: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Urmas, Do you have experimental features enabled? If yes, please disable it and try reproducing again. FWIW, I can't reproduce this anymore. Miklos
I can confirm "Experimental Features" influence with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit), for me unchecking only heals the problem if I restart LibO after undchek.
The same for me: I can confirm "Experimental Features" influence with LibreOffice 3.5.1.2 Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66 German langpack installed running on MacOS X 10.6.8 German. Using the steps given by Rainer Bielefeld in commend #2, I get the following results: -- With "Experimental Features" DISabled, everything works as expected (the five 'a' lines are inserted at the appropriate place). -- With "Experimental Features" ENabled, the bug is still present, including the modification of the Paper Size (A4 before "Paste as RTF", Letter after "Paste as RTF").
Rainer, Roman: so now it's up to you what to do with this bug: 1) just close it, as with experimental features disabled it's fixed or 2) clean up whiteboard, remove regression keyword and make it no longer be a most annoying bug - then we can leave it open till it's even fixed with experimental features enabled. Please do choose one of the above. Thanks!
I can confrim that this bug only shows up with experimental functions turned on. Noth in 3.5.1.2 and in 36-master. However, looking what functions are linked with experimental, I expect that fixing this would be best. (we need a tag for bug related to experimental turned on/off)
Assign it to me, I want to fix this sooner or later.
I am collapsing tag on whiteboard to one word, as suggested by https://wiki.documentfoundation.org/BugReport_Details#Whiteboard A search of bugzilla shows this bug as the only one, so far, with "experimental" on the whiteboard. I have added tags experimentalEnabled and experimentalDisabled to that wiki page. The need for the second of these is merely speculative, of course.
@Terrence Enger: Well done! But Status should be 'Assigned', as we are happy that Miklos has assigned this bug to himself ... much better than 'New', don't you think so?
The 1st version (besides Master) in which this bug occured was 3.5beta1 (see comment #2 and comment #7), therefore changed the Version field back. The version should be either 'LibO Master' (see comment #4; but this is a bit problematic, cf. e.g. http://rrbd.wordpress.com/2012/05/03/how-can-we-allow-more-purposeful-queries-for-version-master/), or 3.5beta1.
Bug still present in Writer/LibreOffice 3.5.4.1. If RTF text is present on the clipboard, Ctrl-V pastes it at the end of the document irrespective of the cursor position.
add to comment 29: provided that experimental features are enabled. With experimental features disabled, paste works correctly.
I'm a third-party developer who's affected by this. We've gotten >5 reports of this issue from users now, even though we have a page describing the problem that's easily accessible. Is a fix forthcoming, or should we try to figure out how to toggle the experimental features pref when we need to use the RTF filter?
as described in comment #15, fixing this would be a bit of work and certainly too risky for the 3.5 release branch.
I mean to use the old RTF filter even when "experimental features" are enabled, not to fix the new RTF filter. Unless there are other experimental features that depend on the new RTF filter, I think this would be a -3 line patch.
Sure, using the old RTF filter for copy&paste in experimental mode would be an easy change, but then we would loose the possibility to use the new RTF filter for copy&paste as a runtime parameter. Please don't forget that in many cases the new RTF filter gives you better results - think of e.g. if you enable experimental features, copy&paste of shapes start to work with the status quo. ;-)
I don't contribute code to LibreOffice, and I don't know your user community very well, so I am aware that my opinion here doesn't really matter. However, I'm skeptical that the number of users who know that the experimental features setting enables the new RTF filter and either only ever paste at the end of the document or are willing to restart LibreOffice to paste a shape exceeds the number of people who are going to enable the experimental features setting, forget about it, and get frustrated that they can't paste anywhere but the end of the document, and that when they use paste something the undo feature no longer works properly. It's possible that this is a more general problem with the idea of shipping the experimental features checkbox. A checkbox that makes random features break in ways that aren't immediately identifiable is both a pretty big footgun for users and a pain for us third-party developers. If you're dead set on using the new RTF filter for paste when experimental features are enabled, maybe you can throw up a dialog or notification of some kind when the user tries to paste RTF somewhere that's not the end of the document so that it's clear why it didn't work, and users don't start pulling their hair out and cursing LibreOffice?
*** Bug 54630 has been marked as a duplicate of this bug. ***
Just for the record: Still reproducible under the known circumstances in LibreOffice 3.6.2.2.
*** Bug 55897 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > Further investigation will show that Paper size will be modified (for me: A4 > to Letter) and also page margins. It seems that for a very short moment a > table will be inserted. For *this* issue, there is the special bug report bug 46669 - “EDITING: Copy/Paste from Text Box changes page layout if Experimental Features enabled”. You will be happy to hear that this issue is fixed now.
This is finally fixed in master with https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=232ad2f2588beff50cb5c1f3b689c581ba317583
Thanks very much for fixing this bug
I second ^that -- thank you very much, Miklós! I am looking forward with great joy to the day the old RTF parser will finally die ...
I thank you too!
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed654c4aa7f9f10fcb16127349009bc0c38b12e8 Revert "fdo#43869 use the old rtf importer for paste" 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.
@ All: I wanted to verify that this bug is fixed, without any unwanted side-effects. However, when I repeat Rainer’s steps from comment #2 with the current 4.0.0beta1 (tested on Mac OS X 10.6.8), I still see a problem: *nothing* is pasted (no “5 rows ‘a’ inserted”). Of course, this is a big progress -- the “xxx” are not deleted, the page format is not changed, and the undo stack is not damaged anymore. But pasting still does not work ... I have filed a new bug report for this special issue: Bug 58327 - “Pasting special some cells ‘As RTF’ from Calc into Writer does not work”. Can some of you who are interested in the present bug please try to reproduce = confirm the new bug 58327? Thank you very much!
Migrating Whiteboard tags to Keywords: (filter:rtf) Replace rtf_filter -> filter:rtf. [NinjaEdit]