Bug Hunting Session
Bug 105164 - The text formatting changes partly to cell formatting when pasting content from one cell to another
Summary: The text formatting changes partly to cell formatting when pasting content fr...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-07 09:56 UTC by Telesto
Modified: 2017-01-15 15:07 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (9.15 KB, application/vnd.oasis.opendocument.text)
2017-01-07 09:57 UTC, Telesto
Details
Example file (9.20 KB, application/vnd.oasis.opendocument.text)
2017-01-12 19:32 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-01-07 09:56:49 UTC
Description:
The text formatting changes partly to cell formatting when pasting content from one cell to another

Steps to Reproduce:
1. Open attached file
2. Drag content of the second cell ('DEF' 'DEF') to cell one ('ABC')

For comparison:
1. Resetting to 'default' pressing CTRL+Z
2. Drag 'GHI GHI' to 'ABC'

Actual Results:  
The second paragraph gets the same as the cell pasting it in

Expected Results:
The pasted formatting should be preserved 


Reproducible: Always

User Profile Reset: No

Additional Info:
Found in
Version: 5.4.0.0.alpha0+
Build ID: 92a1ad1f36b6d3cc13135a8c0805508933011577
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-06_23:42:59
Locale: nl-NL (nl_NL); Calc: CL

and in
Versie: 4.4.6.3 
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
Locale: nl_NL

and in
Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)

and in
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4


User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Telesto 2017-01-07 09:57:07 UTC
Created attachment 130230 [details]
Example file
Comment 2 Cor Nouws 2017-01-07 15:38:14 UTC
(In reply to Telesto from comment #0)

Dragging to 2nd or 3rd paragraph in cell A1:

> Steps to Reproduce:
> 1. Open attached file
> 2. Drag content of the second cell ('DEF' 'DEF') to cell one ('ABC')

second 'DEF' changes to red.

> For comparison:
> 1. Resetting to 'default' pressing CTRL+Z
> 2. Drag 'GHI GHI' to 'ABC'

second 'GHI' remains blue

Note: Start with selecting 2nd and 3rd paragraph in cell A1, and hit Ctrl+M.. then 'DEF' does not change to red.

Version: 5.4.0.0.alpha0+
Build ID: ea860d52ade14b4a16289c81a0f8586799c6617f
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-12-31_01:52:05
Locale: nl-NL (nl_NL.UTF-8); Calc: group
Comment 3 Xisco Faulí 2017-01-12 11:42:05 UTC
Confirmed in comment 2
Comment 4 Cor Nouws 2017-01-12 14:35:52 UTC
(In reply to Xisco Faulí from comment #3)
> Confirmed in comment 2

Hmm, actually my comment is more a question to Telestro: is that how you tested and what you found, because I have the idea that my finding differs, and is related to the direct formatting in cell A1.

Note: cursor in table, Table > Convert > Table 2 text .. Paragraphs, OK ..
perform same test > same result.
Comment 5 Cor Nouws 2017-01-12 14:36:30 UTC
(apologies for not being crisp and clear in my first comment here ;) )
Comment 6 Telesto 2017-01-12 19:32:23 UTC
Created attachment 130370 [details]
Example file

@Cor
I have created a better example to illustrate the inconsistency:
1. Open attached file
2. Drag ABC in the empty space  between ZZZ - ZZZ (second ABC will be red)
3. Reset (CTRL+Z) drag ABC into the empty space between YYY - YYY (second ABC will be red)
4. Reset (CTRL+Z) drag DEF between ZZZ - ZZZ (both will stay black)
5. Reset (CTRL+Z) drag DEF between YYY - YYY (both will stay black)

The text should stay black (as I see it). Same behavior can be found in Word
Comment 7 Cor Nouws 2017-01-13 10:49:25 UTC
(In reply to Telesto from comment #6)
> Created attachment 130370 [details]
> Example file

Thanks.

> @Cor
> I have created a better example to illustrate the inconsistency:
> 1. Open attached file
> 2. Drag ABC in the empty space  between ZZZ - ZZZ (second ABC will be red)
> 3. Reset (CTRL+Z) drag ABC into the empty space between YYY - YYY (second
> ABC will be red)

I confirm that.

> 4. Reset (CTRL+Z) drag DEF between ZZZ - ZZZ (both will stay black)
> 5. Reset (CTRL+Z) drag DEF between YYY - YYY (both will stay black)

That too.
However... now reset. Ctrl+Z, select DEF, Ctrl+M (it has direct formatting, and ABC hasn't) and drag DEF again to ZZZ and YYY areas.
Now it behaves the same as when you drag ABC..
(The other way round, applying Black color to ABC, makes it behave as your DEF.

> The text should stay black (as I see it).

Pasting text without direct formatting in an area with direct formatting, makes the pasted text get the direct formatting.
Pasting text with direct formatting in an area with direct formatting, makes the pasted text retain its original direct formatting.
That is what you found in your initial test too.
And it has nothing to do with a table or not.

I close this issue as NotABug

> Same behavior can be found in Word

And should this be seen as a sign of proper or improper behavior :) ?
But indeed, Word ignores the direct formatting of the area you paste the text without direct formatting.

This could be an issue for debate - how to go around with direct and style formatting in all kind of situations. Depending on probably philosophy, ODF specs, etc..
Comment 8 Telesto 2017-01-15 09:57:43 UTC
@CoR
I'm agreeing with you that my bug report is improper and had to be closed. However the main issue (in my opinion) still persists: pasting text without direct formatting in an area with direct formatting, makes the pasted text get the direct formatting (even when its not intended)

MS Word was only an example. If it was the only application, I could agree. But on the contrary. LibO is the only application I know off which behaves like this (probably I didn't look hard enough :-).
I tested:
- Wordpad
- Mozilla Thunderbird
- Zotero
- Google Docs
- Mac Texteditor
- Pages
- A few online Rich Text Editors

If it should be the normal behavior.
1. Why is the last paragraph getting the direct formatting and not the first one?
2. Shouldn't the formatting automatically extend to every paragraph pasted?


Also a more real life example (making a quite common mistake) Open a new text document. Add, without dashes:
----
ABC


DEF
DEF
----

1. Select ABC (and click on the Font Color Icon (with default color)
2. Hit enter (to accidentally create a row set to red) (There is no way of knowing; Bold/Underline are visible in the toolbar, colors aren't)
3. Drag DEF-DEF under ABC.
4. Second DEF will have a red font color
Comment 9 steve -_- 2017-01-15 12:37:03 UTC
cannot reproduce steps from c#8.

Version: 5.4.0.0.alpha0+
Build ID: 9e7526044c8fa6b006b0cb791d15f2476c96ebf2
CPU Threads: 4; OS Version: Mac OS X 10.12.2; UI Render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-01-14_04:23:59
Locale: de-DE (de_DE.UTF-8); Calc: group

When hitting default font color icon, for me the font color changes (slightly since default is some odd red fairly close to black) but when hitting enter I see no red line.
Comment 10 Telesto 2017-01-15 13:34:38 UTC
I'm creating really creating fuzz being imprecise and not to the point. Shame on me. It's not about a red line or something like that.

I'm talking the reformatting which occurs when cut/pasting (or dragging) a two or more paragraphs without direct formatting into an empty paragraph ('row') where direct formatting (Bold/Italic/Underline/Highlight/Font color) is set.

1. Copy (text between the dashes)
----
ABC 


DEF
GHI
JKL
MNO
DEF
GHI
KLM
NOP
QRS
TUV
WXY
----
2. Note that everything is pasted without direct formatting (Font Color: Automatic)
3. Select ABC (apply some direct formatting; bold/underline/Highlight)
3. Set the cursor after the 'C' and hit enter (creating a new paragraph; which has the same formatting as ABC. Note: can happen by accident).
3. Cut/paste or drag "DEF-WXY" into the paragraph created in step 3.
4. WXY will be formatted to the applied formatting of the paragraph below ABC. The rest will be black without direct formatting (Font Color: Automatic)

In my opinion WXY should also be black (without direct formatting aka Font Color: Automatic). Like the text editor I know do. To format the last paragraph makes it especially odd. If DEF got a direct formatting would suspect a formatting issue, but with WXY..

There are lots workarounds: remove direct formatting from the paragraph below ABC (or setting it to black) or setting DEF-WXY to black (instead of automatic).
Comment 11 steve -_- 2017-01-15 15:07:27 UTC
thx for clarifying. confirming what telesto describes in comment 10.

Personally no strong opinion on this, but would expect to either have all text dragged into a certain formatted paragraph to either adapt the formatting completely or not at all. Only adapting the formatting for the last row seems unexpected and counter-intuitive.

The question now is: what is the "correct" expected behavior. And is notabug still correct. Looking at the title, we've come a long way. Last test did not involve any cells at all. So maybe file a new bug or adjust title? With new bug, this one can remain as is, with changed title, this one here should probebly be reopened?