Bug 43869 - Paste special as RTF inserted at wrong position, undo stack damaged
Summary: Paste special as RTF inserted at wrong position, undo stack damaged
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.5.0 Beta1
Hardware: Other All
: medium critical
Assignee: Miklos Vajna
URL:
Whiteboard: experimentalEnabled target:4.0.0
Keywords: filter:rtf
: 44199 44862 45248 45312 54630 55897 (view as bug list)
Depends on: 46669
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-15 14:28 UTC by Cor Nouws
Modified: 2015-12-17 11:52 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cor Nouws 2011-12-15 14:28:32 UTC
- 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
Comment 1 Cor Nouws 2011-12-15 14:29:53 UTC
seen in master builds before.
IIRC also had some correspondence about this on a list? Cannot remember exactly ;-)
Comment 2 Rainer Bielefeld Retired 2011-12-16 04:10:49 UTC
[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.
Comment 3 Rainer Bielefeld Retired 2011-12-16 05:13:11 UTC
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.
Comment 4 Rainer Bielefeld Retired 2011-12-16 05:24:24 UTC
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)]"
Comment 5 Rainer Bielefeld Retired 2011-12-16 08:06:49 UTC
*** Bug 43480 has been marked as a duplicate of this bug. ***
Comment 6 Rainer Bielefeld Retired 2011-12-16 08:28:44 UTC
<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).
Comment 7 Roman Eisele 2011-12-17 02:04:33 UTC
[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.
Comment 8 Cor Nouws 2011-12-28 05:49:07 UTC
*** Bug 44199 has been marked as a duplicate of this bug. ***
Comment 9 Petr Mladek 2012-01-23 10:34:17 UTC
*** Bug 44862 has been marked as a duplicate of this bug. ***
Comment 10 Miklos Vajna 2012-01-25 04:53:36 UTC
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.
Comment 11 Miklos Vajna 2012-01-25 07:38:20 UTC
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).
Comment 12 Miklos Vajna 2012-01-26 01:51:58 UTC
*** Bug 45248 has been marked as a duplicate of this bug. ***
Comment 15 Michael Stahl (allotropia) 2012-01-26 06:59:59 UTC
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.
Comment 16 Fabio Bugnon 2012-01-31 06:45:03 UTC
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.  ;)
Comment 17 Miklos Vajna 2012-01-31 08:48:22 UTC
*** Bug 45312 has been marked as a duplicate of this bug. ***
Comment 18 Urmas 2012-03-09 09:23:10 UTC
It's definitely in 3.5.1.1.
Comment 19 Only A Test Account, do not aadd to CC! 2012-03-09 12:18:52 UTC
[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
Comment 20 Miklos Vajna 2012-03-12 01:52:12 UTC
Urmas,

Do you have experimental features enabled? If yes, please disable it and try reproducing again.

FWIW, I can't reproduce this anymore.

Miklos
Comment 21 Rainer Bielefeld Retired 2012-03-12 03:36:24 UTC
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.
Comment 22 Roman Eisele 2012-03-12 23:56:36 UTC
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").
Comment 23 Miklos Vajna 2012-03-13 02:42:34 UTC
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!
Comment 24 Cor Nouws 2012-03-13 07:16:43 UTC
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)
Comment 25 Miklos Vajna 2012-03-13 07:53:01 UTC
Assign it to me, I want to fix this sooner or later.
Comment 26 Terrence Enger 2012-03-13 08:17:35 UTC
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.
Comment 27 Roman Eisele 2012-03-13 08:24:19 UTC
@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?
Comment 28 Roman Eisele 2012-05-06 03:56:13 UTC
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.
Comment 29 Kim Bastin 2012-05-20 04:09:48 UTC
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.
Comment 30 Kim Bastin 2012-05-20 04:18:35 UTC
add to comment 29: provided that experimental features are enabled. With experimental features disabled, paste works correctly.
Comment 31 Simon Kornblith 2012-05-22 11:42:21 UTC
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?
Comment 32 Michael Stahl (allotropia) 2012-05-22 11:49:59 UTC
as described in comment #15, fixing this would be a bit of work
and certainly too risky for the 3.5 release branch.
Comment 33 Simon Kornblith 2012-05-30 00:22:17 UTC
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.
Comment 34 Miklos Vajna 2012-05-30 01:19:32 UTC
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. ;-)
Comment 35 Simon Kornblith 2012-06-02 09:38:34 UTC
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?
Comment 36 Rainer Bielefeld Retired 2012-10-11 05:14:38 UTC
*** Bug 54630 has been marked as a duplicate of this bug. ***
Comment 37 Roman Eisele 2012-10-11 09:01:55 UTC
Just for the record:
Still reproducible under the known circumstances in LibreOffice 3.6.2.2.
Comment 38 Roman Eisele 2012-10-13 16:34:39 UTC
*** Bug 55897 has been marked as a duplicate of this bug. ***
Comment 39 Roman Eisele 2012-10-16 15:57:03 UTC
(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.
Comment 40 Miklos Vajna 2012-11-29 21:22:04 UTC
This is finally fixed in master with

https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=232ad2f2588beff50cb5c1f3b689c581ba317583
Comment 41 sasha.libreoffice 2012-11-30 09:21:11 UTC
Thanks very much for fixing this bug
Comment 42 Roman Eisele 2012-11-30 09:30:35 UTC
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 ...
Comment 43 Josep 2012-11-30 12:04:52 UTC
I thank you too!
Comment 44 Not Assigned 2012-11-30 16:42:42 UTC
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.
Comment 45 Roman Eisele 2012-12-15 09:44:38 UTC
@ 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!
Comment 46 Robinson Tryon (qubit) 2015-12-17 11:52:50 UTC
Migrating Whiteboard tags to Keywords: (filter:rtf)
Replace rtf_filter -> filter:rtf.
[NinjaEdit]