Bug 90568 - Confusing behavior with Direct Formatting with copy/paste - when overseeing that default formatting is no direct formatting
Summary: Confusing behavior with Direct Formatting with copy/paste - when overseeing t...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2015-04-11 19:30 UTC by Joel Madero
Modified: 2019-02-02 17:14 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
File Demonstrating Problem (20.13 KB, application/vnd.oasis.opendocument.text)
2015-04-11 19:30 UTC, Joel Madero
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joel Madero 2015-04-11 19:30:10 UTC
Created attachment 114742 [details]
File Demonstrating Problem

Steps to Reproduce:

1. Download file;
2. Copy "(1) No one can petition at park; (neutral)" (pg. 2)
3. Place cursor at end of "Content and Viewpoint Neutral" and hard return
4. Paste


Observed: The copy takes on the direct formatting from "Content and Viewpoint Neutral"


Expected: Whenever you copy/paste a line that has no styles, it should apply *as is* and *not* take on ANY direct formatting from previous lines.


5. Ctrl + z to undo;
6. Paste again

Observed: The paste is *as expected*


Continued (might be a separate issue . . . not really positive)

7. Delete the paste;
8. Repeat steps 2-4
9. Highlight the pasted (with wrong formatting) line;
10. Ctrl + m (clear direct formatting)


Observed: Takes on the formatting from the first line in the document

Expected: All direct formatting is cleared and the font takes on the default values (i.e. black, regular font, regular color, etc . . .)


IMHO this is a minor bug (there are workarounds) but deserves to be on MAB because:

a) Completely breaks workflow;
b) The workaround is tedious and not obvious (ctrl + z and then re-pasting OR manually removing all direct formatting...when using a few combinations it can become a pain in the ass);
c) this is an entirely common thing to want to do (copy and paste with the expectation that direct formatting is maintained)
Comment 1 Yousuf Philips (jay) (retired) 2015-04-11 19:48:21 UTC
Confirmed that when pressing enter at step 3 shows both bold and underline still active and when undoing the paste in step 5, bold and underline are no longer active.

Also confirm that step 7 to 10 are inherited from OOo as well.

Version: 4.5.0.0.alpha0+
Build ID: b024e36ddb3b53163d7a01f6f7b5aadb7a858cd9
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-03-31_08:18:46
Comment 2 Cor Nouws 2015-04-11 19:55:38 UTC
Hi Joel,

Isn't this the same problem as already supported various other times, that when one returns at the end of a position where direct formatting was applied ánd ended earlier in time (by e.g. typing Ctrl+B) that the direct formatting is active..
So is not necessary linked to copy/paste, IMHO.

Cheers,
Cor
Comment 3 Cor Nouws 2015-04-11 19:56:13 UTC
s/supported/reported 
(my head still in some marketing text ;) )
Comment 4 Joel Madero 2015-04-11 20:45:07 UTC
Probably but a couple points:

1. The other one was about use of styles, this one is direct formatting (probably related though)

2. The other bug was closed and UX is discussing how to deal with styles specifically;

3. There's the random workaround (ctrl + z then paste again)

4. I think this one has clearer application to a wider group of users - basically anyone who ever changes a font character and then copies/pastes
Comment 5 Joel Madero 2015-04-11 21:26:06 UTC
Note that the second issue (clearing direct formatting) is separate - please ignore it.
Comment 6 Yousuf Philips (jay) (retired) 2015-04-11 22:20:47 UTC
So the problem being seen in step 4 is that pressing enter in step three, on a line which has a character style and then pasting results in the character style still remaining active. But when pressing undo in step 5 results in the character style being reset to default.
Comment 7 tommy27 2016-04-16 07:27:58 UTC Comment hidden (obsolete)
Comment 8 Octavio Alvarez 2016-09-18 23:05:42 UTC
The behavior Joel is experiencing can be explained with a simpler example:

1. Start a new Writer document.

2. Type "abcde" and hit Enter.

3. Set size to 36, type "12345" and hit Enter.

4. Set size to 72, type "ABCDE" and hit Enter.

5. Select "2"; copy; place cursor between "b" and "c"; paste. Number "2", originally big is pasted big.

6. Select "d"; copy; place cursor between "3" and "4"; paste. Letter "d", originally small is pasted big. Wow!

7. Select "D"; copy; place cursor between "4" and "5"; paste. Letter "D", originally giant is pasted giant.

What's happening: "2" had a DF[*] applied and the DF gets copied along with it onto the target. However, "d" does not have any DF, so it gets pasted without any overriddance on the target paragraph. Technically, the program is behaving but it's counter-intuitive.

The problem does not happen if in step #2 we set size to 12 before writing "12345". It makes sense why.

So, just to be picky with Joel's conclusion "c)": in the current state of the art, the DF *is* maintained in the sense that the original paragraph had Font and Indent as DF and *got kept*. But it didn't have any Color or Underline setting as DF (it was "auto/inherit") so it got inherited from the "format to apply if I just started to type".

From a strictly technical PoV this is correct behavior. I agree though that this is visually unexpected and should be improved.

[*] Direct Formatting
Comment 9 Cor Nouws 2016-09-27 08:38:59 UTC
(In reply to Octavio Alvarez from comment #8)
> The behavior Joel is experiencing can be explained with a simpler example:

thanks - nice explanation!
Comment 10 QA Administrators 2017-10-23 14:11:24 UTC Comment hidden (obsolete)
Comment 11 Cor Nouws 2017-12-30 11:37:38 UTC
behavior still the same, obviously. Better summary ?
Comment 12 Cor Nouws 2017-12-30 11:40:11 UTC
(In reply to Octavio Alvarez from comment #8)
 
> From a strictly technical PoV this is correct behavior. I agree though that
> this is visually unexpected and should be improved.

So how should that be achieved, without introducing undesired behavior? I mean, it may well be expected by users, that pasting text without DF (the 12345) adapt when pasted in DF text.
At the moment, I tend to choose for closing as NotABug
Comment 13 Octavio Alvarez 2018-01-02 03:31:38 UTC
What about this:

Considering we have "Paste unformatted" easily available, then regular Paste should include all formatting. If it's only text then character formatting only.

When pasting with formatting, all formatting should be pasted but attributes should be "merged down" with the target paragraph style (but character styles also), for example:

If the target paragraph underlying style says text is red, then:

* Pasting text that is directly-formatted red should result in no formatting attributes (the underlying paragraph would make it red anyway).

* Pasting text from a bold + black paragraph style but directly-formatted regular should result in directly-formatted black only (the directly-formatted regular should go away because the underlying paragraph [and character?] style is already regular).

* Pasting text that is paragraph-styled blue + directly-formatted bold should result in directly-formatted blue + bold.

* Pasting text that is paragraph-styled bold + character-styled blue + directly-formatted red should result in character-styled blue + directly-formatted red + bold.

These examples are incomplete as we would have to account for a better-specified interaction with character styles, but I hope I passed my point across: copy and paste with all formatting but reduce the pasted text formatting to the least possible amount of direct-formatting attributes.
Comment 14 QA Administrators 2019-01-26 03:48:15 UTC Comment hidden (obsolete)
Comment 15 Timur 2019-01-28 13:43:05 UTC
There's some mess here. 
I understand bug was about "Undo" issue and Octavio's comments are not related.
Comment 16 Octavio Alvarez 2019-01-29 00:54:21 UTC
(In reply to Timur from comment #15)
> There's some mess here. 
> I understand bug was about "Undo" issue and Octavio's comments are not
> related.

He is clearly stating Observed vs Expected behavior *before* the Undo operation and the Undo operation *fixes* it (makes the Observed behavior actually match the Expected behavior). Additionally, Undo is not in the summary.
Comment 17 Timur 2019-01-29 08:33:52 UTC
I do not agree with that conclusion. 
Instead of just clearing up why Undo removes formatting (even though the example is not minimized so is not adequate), which is inconsistent behavior, you are piggybacking the change of logic that's questionable at least. 
We have Bug 83102 for merging and Bug 42638 for options and that's as far as I think we'll go. 
Not "read" formatting from style and paste to another style as direct formatting, as I understand your Comment 8.
Comment 18 Heiko Tietze 2019-01-31 15:16:48 UTC
Let's start with the simplest workflow: The paragraph has direct formatting and you add content at the end. The formatting should persist in this case of course. Whether typing or pasting a few words shouldn't make a big difference, so the current behavior is correct. If you copy/paste more than a few words, meaning a full paragraph such as from (2) including the line wrap until (3) at the example, the pasted paragraph shouldn't change it's style/formatting. And this works also as expected.

What remains is the weird Undo that clears the direct formatting. It also happens when you type something and undo this. I recommend to close this issue as WFM and to open a new ticket for the undo bug.
Comment 19 Cor Nouws 2019-02-02 17:13:46 UTC
Sorry for all that have put energy in discussing and understanding, but there it's not convincing that hacking in this will make an improvement.. - comment #12 and comment #17 and comment #18 suggest to close as WFM / NotABug. Doing so now.
Comment 20 Cor Nouws 2019-02-02 17:14:31 UTC
and indeed: if desired, look at reports linked in comment#17