Bug 111349 - Error in pasting as unformatted text (steps in comment 5)
Summary: Error in pasting as unformatted text (steps in comment 5)
Status: RESOLVED DUPLICATE of bug 115088
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2017-08-04 15:39 UTC by John
Modified: 2018-02-09 15:28 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
tail of terminal output from bibisect (2.31 KB, text/plain)
2017-12-27 18:30 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John 2017-08-04 15:39:00 UTC
New odd behaviour with 5.4.0.3 x64 on Win10 x64.

I cut and paste a lot in writing reports and do not usually want the source formatting, so generally paste as "unformatted text". I often do this between pre-prepared quote marks. The unformatted text paste now puts the trailing quote in the wrong place.

Steps to reproduce:-

1. Create a new blank document
2. Write some words with a line break in there somewhere. This will be the source text (mine is usually from Acrobat pdf's but this doesnt matter)
3. Prepare some target text - "" will do nicely
4. Select and Ctrl-C the text created in (2)
5. Place the cursor between the characters created in (3) and Ctrl-V. The text will appear correctly between the ""
6. Repeat from (3) but this time, on pasting, paste using Ctrl-shift-V and select unformatted text. Now the trailing quote appears incorrectly at the end of the first line of the pasted text, rather than at the end of the whole block.

A small bug, but I am having to make a lot of manual adjustments to correct for it.
Comment 1 V Stuart Foote 2017-08-04 17:33:11 UTC
Confirmed the placement of a closing quote is made at the end of the first paragraph/linebreak from pasted material. But it happens for any target text in a paragraph.

On Windows 10 Ent 64-bit en-US with
Version: 5.4.0.3 (x64)
Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
Locale: en-US (en_US); Calc: group

Note: if the copied text has line continuations <Shift><Return> rather than new lines the target is split to the end of the pasted content. Seems composing the paste result is incorrectly stopping with the first new line.
Comment 2 John 2017-09-01 19:38:46 UTC
Just to confirm that this is still present in 5.4.1.2.
Comment 3 John 2017-10-07 09:52:59 UTC
Just to confirm that this bug is still present in 5.4.2.2 x64
Comment 4 John 2017-12-23 11:11:07 UTC
Just to confirm that this is still present in 5.4.4.4 and 6.0.0.1. I am left stuck on 5.3x :(
Comment 5 V Stuart Foote 2017-12-23 13:38:58 UTC
QA note: Version is the earliest build an issue is reproducible. Please do not adjust unless performing bibisect.

Simpler STR, prepare new document with "" target marker. Position cursor between marks. Open Help -> About dialog, select and <Ctrl>+c to copy its text. 

As selection here will "only" be unformatted text, Close the dialog to return cursor focus to document at the target. A <Ctrl>+v to paste the unformatted text.

Closing quote of marker will be positioned to end of the first paragraph of the pasted text.
Comment 6 Terrence Enger 2017-12-27 18:30:59 UTC
Created attachment 138692 [details]
tail of terminal output from bibisect

I see the bug in, for exmaple, daily Linux dbgutil bibisect repository
version 2017-12-16.  So I am setting O/S = All.

Working on debian-buster in the till54 bibisect repository, I see that
the bug entered LO somewhere in the 62 or so commits

          commit    date        s-h
          --------  ----------  --------
    good  ea8b303b  2017-04-25  e4f28aea
    bad   96ac09db  2017-04-26  d8a56401

I am removing keyword bibisectRequest and adding keywords regression,
bibisected.

In the bibisected range, I notice commit e68b6e34, "Optimize
plain-text import".  Michael, are you interested?
Comment 7 Xisco Faulí 2017-12-27 18:54:25 UTC
Confirmed.
Regression introduced by:

author	Michael Meeks <michael.meeks@collabora.com>	2017-04-24 14:58:54 +0100
committer	Michael Meeks <michael.meeks@collabora.com>	2017-04-25 16:49:41 +0200
commit	e68b6e349c31ac1376e90218013e1e7612f2b522 (patch)
tree	b1c19255d11dc1e99c08b71b4ae12e31412bef7b
parent	dec025d4cb51f252ecd7e981fe36800cf2bedff5 (diff)
Optimize plain-text import.
Cost of managing rsids is very significant >50% of import time, new
Rsids will be generated for changes anyway.
Also avoid un-necessary splitting of paragraphs on new-line.

Bisected with: bibisect-linux-64-5.4

Adding Cc: to Michael Meeks
Comment 8 Telesto 2017-12-28 08:11:18 UTC
*** Bug 114706 has been marked as a duplicate of this bug. ***
Comment 9 Kevin Suo 2017-12-28 11:35:34 UTC
Bug 114706 contains more general case to reproduce.
Comment 10 V Stuart Foote 2017-12-28 19:26:03 UTC
(In reply to Kevin Suo from comment #9)
> Bug 114706 contains more general case to reproduce.

Yes, agree it is not related to the delimiters, "" or any other. Issue is with the plain text paste/import action.
Comment 11 Kevin Suo 2018-02-09 15:21:42 UTC
*** Bug 113708 has been marked as a duplicate of this bug. ***
Comment 12 Kevin Suo 2018-02-09 15:28:47 UTC
This (and its duplicates) mudt be a duplicate of bug 115088 which is just now fixed. The have the same bisect result.

Need to test against the most recent version.

*** This bug has been marked as a duplicate of bug 115088 ***