Bug 63319 - EDITING: copy paste text from gedit editor
Summary: EDITING: copy paste text from gedit editor
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.5.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2013-04-09 15:07 UTC by Dmitry
Modified: 2024-11-06 20:49 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
content.xml file (3.10 KB, application/xml)
2013-04-10 08:24 UTC, Dmitry
Details
Comparison between Geany+Crunchbang11 vs gedit+Ubuntu1004. (41.27 KB, application/zip)
2013-11-22 12:24 UTC, Owen Genat (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry 2013-04-09 15:07:31 UTC
Problem description: when i copy&paste some text from gedit.
Libreoffice inserts before each newline single space symbol.

Steps to reproduce:
1. open gedit and print some text with newline(s): "aaa\nbbb\nccc"
2. open writer and copy-paste this text into new document
3. save like smth.odt

Current behavior:
After saving file looks pretty good, but if we close and open stored file the text will be "aaa \nbbb \nccc". Inside odt-archibe content.xml data tag which should contain "aaa" contains "aaa
".

If we create new odt file and print text "aaa\nbbb\nccc", store and open it we'll see good text. Value inside content.xml is "aaa".

Expected behavior:
Data tage in content.xml should contain "aaa" instead of "aaa
".

System: Debian Squeeze, Linux 2.6.32-5-amd64 #1 SMP x86_64
System charset: UTF-8

Operating System: Debian
Version: 3.6.5.2 release
Comment 1 Tim Lloyd 2013-04-10 05:14:54 UTC
Hi, unable to reproduce with 3.8.3-203.fc18.i686.PAE and LO 3.6.5.2. Any more information available pls?

Did you type anything else into either gedit or writer?

Tks
Comment 2 Dmitry 2013-04-10 08:24:04 UTC
Created attachment 77725 [details]
content.xml file

contains result of text "aaa\nbbb\nccc" storing by copy paste from gedit to libreoffice
Comment 3 Dmitry 2013-04-10 08:25:52 UTC
No, noting else was printed either gedit or writer.
Tried to reproduce same thing with Libreoffice 3.5.4.2 and got same result.
Debian Squeeze, Linux 2.6.32-5-686 #1 SMP.
I've added content.xml sample.
Comment 4 Dmitry 2013-04-10 08:39:24 UTC Comment hidden (me-too)
Comment 5 Dmitry 2013-04-10 08:39:57 UTC
The bug is reproducable also with Xubuntu system, copy from mousepad-editor and insert into Libreoffice document (4.0.1.2).
Linux 3.8.0-17-generic #27-Ubuntu SMP i686
Comment 6 Dmitry 2013-04-17 10:48:50 UTC
Additional information: all systems have UTF-8 as the default character set. All mentioned Libreoffice versions are for Russian language.
Comment 7 Owen Genat (retired) 2013-11-22 12:24:46 UTC
Created attachment 89636 [details]
Comparison between Geany+Crunchbang11 vs gedit+Ubuntu1004.

There has long been a problem with pasting plain text under Ubuntu 10.04 x86_64 from gedit v2.30.3 into various versions of LO. I have tested these versions:

- v3.3.0.4 OOO330m19 Build: 6
- v3.4.6.2 OOO340m1 Build: 602
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a

The behaviour is identical for all versions and exactly as described in comment #0. The on screen display differs across versions as the screenshots show i.e., v4.0.6.2 and v4.1.3.2 show a large crossed out rectangle character that appears to be a carriage return (U+000d) as indicated in the report. In earlier versions the character does not display but it does impede cursor movement.

For comparative purposes the same text entered into geany (text editor) under Crunchbang 11 x86_64 is also included. The original text files created by geany and gedit appear byte-for-byte identical (refer hexdumps) so the problem would seem to be either with gedit or the way in which LO is interpreting the clipboard data produced by gedit.
Comment 8 Owen Genat (retired) 2013-11-22 12:28:51 UTC
As per comment #7, confirmed. Status set to NEW. Version set to Inherited From OOo. I have only tested Writer, but if it is a clipboard issue then another component may be more appropriate.
Comment 9 QA Administrators 2015-04-19 03:21:48 UTC Comment hidden (obsolete)
Comment 10 Alex Thurgood 2015-12-28 08:05:33 UTC
Still an issue, at least on OSX, and has been for a while, however, this is not inherited from OOo, it has only recently appeared (as in, somewhere in the 4.x or 5.x branch)
Comment 11 Alex Thurgood 2015-12-28 08:06:22 UTC
*** Bug 96731 has been marked as a duplicate of this bug. ***
Comment 12 Alex Thurgood 2015-12-28 08:08:22 UTC
On OSX, the problem occurs when one copy/pastes text from within a Writer document.
Comment 13 MarjaE 2015-12-28 14:01:09 UTC
(In reply to Alex Thurgood from comment #12)
> On OSX, the problem occurs when one copy/pastes text from within a Writer
> document.

I'm not sure these are the same bug. I think the Writer bug was introduced by the "fix" to "bug" 34614.
Comment 14 QA Administrators 2017-01-03 19:54:40 UTC Comment hidden (obsolete)
Comment 15 Dmitry 2017-02-09 18:27:20 UTC
The problem still exists, so many years passed. :(
Tested on version 5.2.2.2.

Text "aaa bbb cd".

ACT-1:
Copying "bbb", insert it between "c" and "d", result "aaa bbb c bbb d".

ACT-2
Copying "bbb", put cursor after "d", press space, make insert, result "aaa bbb cd  bbb". Two spaces!!!

Even when I need space before/after, I'm not sure that inserted symbol is really space (0x32). I have to move cursor to that blanks, remove them, add space.

IMHO, PC must do what it is told to, without such "care".
Really piss me off.
Comment 16 Xisco Faulí 2017-04-13 08:49:09 UTC
Putting back to NEW as there's no assignee to this bug
Comment 17 LeMoyne Castle 2017-04-19 01:06:19 UTC
Changed version on bug from inherited to version 3.6.5.2 of first report. 

Testing with Ubuntu Xenial stock LibreOffice: 
Version: 5.1.6.2
Build ID: 1:5.1.6~rc2-0ubuntu1~xenial1
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group


I get a different but still incorrect behavior. 
Can copy+paste between Geany and Gedit just fine. 
Copy+paste from either Geany or Gedit into LibreOffice *loses* the last character  if the copied text ends with either a blank space or a newline.  Otherwise, when the selection ends in a non-white (alphabetic) character, the copy+paste seems to work fine. So... it's not Gedit, etc. - it is LO. 

1. I did not reproduce the originally reported buggy behavior - more like the inverse action - lost a character instead of getting an extra.  
2. I tested with an older version of LO than Dmitry in his most recent test. 
3. Could not reproduce reported extra character problem appearing after save+load.  [the lost char didnt re-appear either]
4. No visible problem doing copy+paste FROM LibO.

Upshot: LibreOffice 5.1.6.2 is losing terminal whitespace char in the paste from clipboard.
Comment 18 QA Administrators 2018-07-04 02:48:55 UTC Comment hidden (obsolete)
Comment 19 QA Administrators 2020-07-04 03:36:55 UTC Comment hidden (obsolete)
Comment 20 QA Administrators 2022-07-05 03:49:32 UTC Comment hidden (obsolete)
Comment 21 QA Administrators 2024-07-05 03:15:00 UTC Comment hidden (obsolete)
Comment 22 Mike Kaganski 2024-11-06 09:51:52 UTC
It seems to be a mix, with Dmitry themself joining the "change me arbitrarily" party.

In comment 0, the description was, that copying a multiline text from a plain text editor (gedit) and pasting into Writer produces a correct look, but after save-and-reload, additional "spaces" appear, which weren't present before reload, and which likely represent CR characters.

In comment 7, 8, this has beet confirmed, with testing over several versions, including 3.3, up to 4.1.

Then suddenly, in comment 10, there is a claim that this is not old, and just appeared (on macOS). Then in comment 12, it is likely clarified, that it's something different; and that was pointed out in comment 13.

And now, in comment 15, Dmitry decided to add confusion, writing something completely different (in fact, both comment 13 and comment 15 are bug 112011).

Finally, comment 17 is about yet another thing (as it's explained there, it's the opposite to what was reported initially).

I put it to NEEDINFO, to clarify one single thing: is the description in comment 0 (as confirmed in comment 7) still reproducible? This is the only thing to decide if this is NEW or WORKSFORME. Bug 112011 is unrelated; and the problem in comment 17, if exists, needs an own report.
Comment 23 MarjaE 2024-11-06 20:49:31 UTC
Unable to reproduce original bug using xed and LibreOffice 24 in Fedora 40.