Bug 45501 - Indenting change when copy & paste in list (steps to recreate: comment 16)
Summary: Indenting change when copy & paste in list (steps to recreate: comment 16)
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: All All
: high minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
: 103563 (view as bug list)
Depends on:
Blocks: Paste Bullet-Number-Outline-Lists
  Show dependency treegraph
 
Reported: 2012-02-01 06:44 UTC by vitruss
Modified: 2019-09-09 13:09 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document. (8.83 KB, application/vnd.oasis.opendocument.text)
2012-02-01 06:44 UTC, vitruss
Details
Another test file to reproduce the problem. (18.05 KB, application/vnd.oasis.opendocument.text)
2016-11-01 17:31 UTC, Hans Deragon
Details
Video showing the problem. (292.93 KB, video/ogg)
2016-11-01 17:31 UTC, Hans Deragon
Details
Test case with normal (text body) style (11.00 KB, application/vnd.oasis.opendocument.text)
2017-06-10 14:24 UTC, András Novoszáth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description vitruss 2012-02-01 06:44:02 UTC
Created attachment 56451 [details]
Test document.

Fromating is changed to default on every drag and drop or copy/paste action in numbered lists.

Steps to reproduce:

1. Open attached document.
2. Copy the text "Text." from the first string.
3. Paste to the last.

Actual Results: The formating changes to the default (aligned at 0.67 cm, indent to 1.27 cm)

Expected Results: No change in formating of the list.

The same result occurs if any letters are drag and dropped using mouse. The same behavior is for bullets, not numbers for the list.
Comment 1 A (Andy) 2013-05-02 19:49:01 UTC
reproducible with LO 4.0.2.2 (Win7 Home, 64bit)
Comment 2 tommy27 2014-04-23 12:51:19 UTC
reproducible in Win7x64 using LibO 4.2.3.3
platform --> ALL
Comment 3 QA Administrators 2015-06-08 14:43:03 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2015-08-02 11:33:23 UTC
1. Test. had all indent settings 0
When I paste the text to replace the lower one, the 2. Test. indent settings changed to
Before text: 3.43 ch
First line: -1.71 ch

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 902255645328efde34ddf62227c8278e8dd61ff0
TinderBox: Win-x86@39, Branch:master, Time: 2015-07-30_03:52:07
Locale: en-US (fi_FI)
Comment 5 QA Administrators 2016-09-20 10:21:51 UTC Comment hidden (obsolete)
Comment 6 vitruss 2016-09-20 11:02:57 UTC
No changes in the behaviour.
Still present:
Version: 5.2.1.2
Build ID: 31dd62db80d4e60af04904455ec9c9219178d620
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
Locale: ru-RU (ru_RU); Calc: group
Comment 7 Hans Deragon 2016-10-31 13:52:10 UTC Comment hidden (obsolete)
Comment 8 Hans Deragon 2016-10-31 13:53:06 UTC
Sorry, pasted my comment in the wrong bug report.  I meant to say that bug #103563 could be a duplicate of this one.
Comment 9 Buovjaga 2016-11-01 17:14:51 UTC
*** Bug 103563 has been marked as a duplicate of this bug. ***
Comment 10 Hans Deragon 2016-11-01 17:28:29 UTC
Confirmed in

- Version: 5.3.0.0.alpha0+
Build ID: 8974b0fafb18f9dd3f2c0e175a3255b80e4c249e
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

- Version 5.2.3.2 on Ubuntu 16.04 LST Xenial Xerus.

- Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

- LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 11 Hans Deragon 2016-11-01 17:31:22 UTC
Created attachment 128407 [details]
Another test file to reproduce the problem.
Comment 12 Hans Deragon 2016-11-01 17:31:56 UTC
Created attachment 128408 [details]
Video showing the problem.
Comment 13 Regina Henschel 2016-11-05 18:36:30 UTC
The numbering style WW8Num6 has no distance settings in the tab Position. Therefore when recalculating the line after pasting the word, the default values are used.

To investigate, why the settings are missing, the original Word document is needed. Please attach it.
Comment 14 Hans Deragon 2016-11-06 13:40:02 UTC
I assume you have analysed 'LibreOffice - Bug #45501 - Paragraph Indentation change after paste.odt'.

This file is actually a snippet of my resume, which was converted from a doc file more than a decade ago; that file doc file has been deleted long time ago.

Would it be possible to have the document healed automatically?  Before the pasting, the line has a proper indent.  If none is found in styles, it should use the existing one instead of the default one, and fix the style automatically.
Comment 15 Regina Henschel 2016-11-06 14:36:26 UTC
Yes, I have analyzed the attachment 'Another test file to reproduce the problem'. The list items have got paragraph style "Indent 1 - Bulleted" and this style is connected to the numbering style "WW8Num6". And this style misses same position information.

The attachment 'Test document' has the problem, that the numbering format has position values different to those currently in the paragraph. There too further investigation is only possible, when we know, how the file has been created.

To repair the file, edit the style "WW8Num6" and enter in tab Position (decimal depends on your language):
Aligned at: 0.64cm (which is 1.12cm - 0.48cm from the paragraph style)
Tab stop at: 1.12cm
Indent at: 1.12cm

Then pasting will work without problems. You might need to edit the other used numbering styles in similar way.
Comment 16 vitruss 2016-11-06 15:04:46 UTC
I recalled how the document was created and have reproduced this in new file.

1. Create new writer document (LO 5.2.2).
2. Type "Test."
3. Create numbered list.
4. Press enter and type "Test." on the second line.
5. Select all using mouse or ctrl+a.
6. Change the indentation moving sliders: bottom one to zero, top one to zero.
7. Select and copy text from the first line.
8. Paste to the second line.

Voila: indentation has changed.

Hope this helps to solve the issue.
Comment 17 vitruss 2016-11-06 15:05:28 UTC Comment hidden (obsolete)
Comment 18 Regina Henschel 2016-11-06 17:51:19 UTC
Thanks vitruss, now it is clear how to reproduce the bug.

I see these problems:
(1) Applying a numbering style removes the settings fo:text-indent from the paragraph style in content.xml. That should not happen.
(2) If the paragraph style in content.xml has no setting for fo:text-indent but the parent style in styles.xml has a setting for fo:text-indent, then the settings from the parent style are not considered.
(3) Copy&paste a single word from a paragraph in a list item adds a list-style to the target paragraph style in content.xml.

The relevant part in spec is:
ODF 1.2 part 1 section 19.246fo:text-indent 
"The fo:text-indent attribute specifies the indent for the text lines of a list item. The attribute has the same meaning as the formatting property attribute fo:text-indent. See 20.218 It is used for paragraphs inside list items whose paragraph styles do not specify an fo:text-indent or fo:margin-left attribute."

In my understanding, this means, that in case a paragraph style has a setting fo:text-indent, it takes precedence over the setting form the list style.
Comment 19 Hans Deragon 2016-11-06 18:03:08 UTC
Reproduced vitruss's test with a new document on Version: 5.2.3.2
Build ID: 1:5.2.3~rc2-0ubuntu1~xenial1.

So forget about my attachment (Another test file...), file which is buggy from a conversion done from MS Word with OpenOffice, long long time ago in a different galaxy.

His manual test from a new document is the best.  I also recreate this morning my resume from scratch and still have the same problem.
Comment 20 Hans Deragon 2016-11-07 14:51:26 UTC
Given that copy & paste within lists are very common, that bug is very visible to a great number of users.  Shouldn't the importance be increased?
Comment 21 Buovjaga 2016-11-07 17:33:52 UTC
Raising priority to high.
Comment 22 Lê Xuân Định 2017-06-01 08:44:29 UTC
Reproducible in version 5.2.7.2 (x64) for both ordered and unordered lists.

This bug is very much annoying!!!! I'm working a lot on lists and really can't stand with such a stupid behavior! :( I can't understand why such a bug can live for more than 5 years, while LibreOffice is just 6 year old!

Using the testcase with new document in Comment #17 and extended for unordered lists, this bug is reproducible in version 5.2.7.2 (x64).

If no one care about this bug, I must dig into it myself. But I'm completely new to LibreOffice. So I hope some experienced devs can help me in resolving this bug.
Comment 23 Buovjaga 2017-06-01 08:58:24 UTC
(In reply to Lê Xuân Định from comment #22)
> Reproducible in version 5.2.7.2 (x64) for both ordered and unordered lists.
> 
> This bug is very much annoying!!!! I'm working a lot on lists and really
> can't stand with such a stupid behavior! :( I can't understand why such a
> bug can live for more than 5 years, while LibreOffice is just 6 year old!
> 
> Using the testcase with new document in Comment #17 and extended for
> unordered lists, this bug is reproducible in version 5.2.7.2 (x64).
> 
> If no one care about this bug, I must dig into it myself. But I'm completely
> new to LibreOffice. So I hope some experienced devs can help me in resolving
> this bug.

LibreOffice has a long history :) https://en.wikipedia.org/wiki/StarOffice

If you want to help: https://wiki.documentfoundation.org/Development/GetInvolved
Comment 24 Buovjaga 2017-06-01 19:12:10 UTC
Lê Xuân: I saw you join the developer IRC, but for some reason you said "May I humbly bring to attention to Devs the following bug which I feel is hurting LO´s reputation?" I thought you were going to look into fixing it. Now the developers thought you want them to fix it for you.

I think you should observe what happens when the bug occurs. Do it with a debugger: https://wiki.documentfoundation.org/Development/How_to_debug
Then you will find out the code that is responsible and can do digging. If you get stuck, then you can ask developers for help.
Comment 25 Hans Deragon 2017-06-01 19:54:20 UTC
It was not Lê Xuân who joined IRC, but me.
Comment 26 András Novoszáth 2017-06-10 14:24:58 UTC
Created attachment 133943 [details]
Test case with normal (text body) style

1. Copy/pasting the lorem ipsum text in the third paragraph on the second paragraph automatically sets the new text 0.76 "Before text" and -0.76 "First line" indent. When pasting it to the first paragraph, this does not occur.
2. This does *not* work with text pasted from an external source.
3. For some reason, the second and the third paragraph has "decrease indent" function turned off, while for the first paragraphs it is allowed.
Comment 27 András Novoszáth 2017-06-10 14:28:13 UTC
Comment on attachment 133943 [details]
Test case with normal (text body) style

I produced it on an Ubuntu 16.04 LTS, with LibreOffice 5.1.6.2
Comment 28 András Novoszáth 2017-06-11 14:02:36 UTC
(In reply to András Novoszáth from comment #26)
> Created attachment 133943 [details]
> Test case with normal (text body) style
> 
> 1. Copy/pasting the lorem ipsum text in the third paragraph on the second
> paragraph automatically sets the new text 0.76 "Before text" and -0.76
> "First line" indent. When pasting it to the first paragraph, this does not
> occur.
> 2. This does *not* work with text pasted from an external source.
> 3. For some reason, the second and the third paragraph has "decrease indent"
> function turned off, while for the first paragraphs it is allowed.

Additional observation:

4. When I try to turn numbering on the third paragraph it does not work, but instead, it seems to reformat it in the same way the copy/paste does on the second. For bullets, this does not occur.
Comment 29 QA Administrators 2018-07-06 02:46:25 UTC Comment hidden (obsolete)
Comment 30 Timur 2019-09-09 12:58:59 UTC
Original test document works fine with LO 6.2 and 6.4+. I'll close.
Comment 31 Timur 2019-09-09 13:04:51 UTC
This started in 3.4, 3.3 was fine. 
Bug 103563 is not resolved.
Comment 32 Timur 2019-09-09 13:09:09 UTC
As explained earlier that attachment 128407 [details] has some issues and was created long ago, I will not reopen Bug 103563.