Repro.

Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+
Build ID: b89feb8018bf3610faf01e73995d576f6566e20b
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-03-07_03:36:17
Locale: fi-FI (fi_FI)

Is this the same issue or has it the same cause as bug 107857?

No, because this is about paragraph styles and here no selection is involved.

Still present in:

Version: 6.1.6.3 (x64)
Build ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU threads: 4; OS: Windows 6.1; UI render: default; 
Locale: en-US (en_US); Calc: group threaded

Cannot repro general problem described in the summary with 6.3.4.2

For example:

1. Make a text line with style 'Heading 1'
2. Make a text line with style 'Text Body'
3. Make a text line with style 'Heading 2'
4. Copy a piece of the text in the 'Heading 1' style line and paste into the other two. (or any other combination)

Actual result:  The pasted text adopts the style of the line where it was pasted. 

Have I misunderstood the problem report?  or maybe WFM?

Or is this bug a duplicate of bug 100018 -- which is specifically about footnote?

Hi,

Yes, you misunderstood. The problem is when a new style has been selected *but nothing has yet been written in the new style*, and then something in a different style is pasted into it. The pasting reverts the new selected style back to the old style. This is most prominent and problematic in footnotes, but it happens across the board. E.g., try writing something in default style, then set a new line to a different style (Heading 1 or whatever), but don't write anything. Then copy the line written in default style and paste it into the new line set to the different style but which hasn't had anything written yet. Actual result is that the pasted text reverts to the old style, while expected result is that the text is pasted in the new selected style.

I just tried this with 6.3.4.2 and the bug is still present.

(In reply to sdc.blanco from comment #10)
> Cannot repro general problem described in the summary with 6.3.4.2
> 
> For example:
> 
> 1. Make a text line with style 'Heading 1'
> 2. Make a text line with style 'Text Body'
> 3. Make a text line with style 'Heading 2'
> 4. Copy a piece of the text in the 'Heading 1' style line and paste into the
> other two. (or any other combination)
> 
> Actual result:  The pasted text adopts the style of the line where it was
> pasted. 
> 
> Have I misunderstood the problem report?  or maybe WFM?
> 
> Or is this bug a duplicate of bug 100018 -- which is specifically about
> footnote?

(In reply to William Friedman from comment #11)
> Yes, you misunderstood. The problem is when a new style has been selected
Thanks for clarification. Now I can reproduce what you describe.

Try this one. Follow your procedure, but use Ctrl-Alt-Shift-V (paste unformatted) when you paste to the empty line (with a different paragraph style).  Should do what you were expecting.

Will add needsUXeval so that you can get a resolution, but I predict that you will be told that this is by design (and that you should use Ctrl-Alt-Shift-V), and not a bug. (See bug #100018 comment 7)

(In reply to sdc.blanco from comment #12)
> (In reply to William Friedman from comment #11)
> > Yes, you misunderstood. The problem is when a new style has been selected
> Thanks for clarification. Now I can reproduce what you describe.
> 
> Try this one. Follow your procedure, but use Ctrl-Alt-Shift-V (paste
> unformatted) when you paste to the empty line (with a different paragraph
> style).  Should do what you were expecting.
> 
> Will add needsUXeval so that you can get a resolution, but I predict that
> you will be told that this is by design (and that you should use
> Ctrl-Alt-Shift-V), and not a bug. (See bug #100018 comment 7)

The problem with this solution (as I wrote in response to a similar suggestion just today over on bug #100018) is that "paste unformatted" removes all attributes, including bold, italics, etc. (This is represents my typical use case: a bunch of text written with such attributes that I move from the body to a footnote.) It is therefore *not* what I'm expecting. It is also very strange behavior (as someone wrote over on that bug): why should pasting into a style that already has but a single space preserve all the attributes of the pasted text but change its style, while doing so without the space reverts the style (and, in the case of footnotes, completely messes up the formatting)? If this is truly by design, it seems like a very odd choice that requires some justification. Thank you for adding the relevant tag.

One further issue regarding the "solution" to insert a single space: if the pasted text has a hard return in it, then all the lines after the hard return will be pasted in the original style rather than the new one. This is easy to reproduce: Type two lines of text separated by a hard return, then start a new line in a different style, insert a space, and paste the two lines of text. The first line before the hard return will be in the selected style, and the line after the hard return will be in the text's original style. There needs to be a way to paste text from one style to another without losing the character attributes (bold, italics, etc.).

The current solution with applying the source style if the target paragraph is not empty (unless it's a footnote, see bug 100018 comment 15) is correct. Changing this leads to much more regression and confusion.

(In reply to William Friedman from comment #14)
> One further issue regarding the "solution" to insert a single space: if the
> pasted text has a hard return in it, then all the lines after the hard
> return will be pasted in the original style rather than the new one.

I agree here that users expect either source or target style but not a mixture.

(In reply to Heiko Tietze from comment #15)
> The current solution with applying the source style if the target paragraph
> is not empty (unless it's a footnote, see bug 100018 comment 15) is correct.
> Changing this leads to much more regression and confusion.

Wait, that's not what happens. The source style (i.e., the style of the copied text) is applied only if the target paragraph *is* empty; if the target paragraph is *not* empty, then the source text is changed to the target paragraph's style. I agree that the latter behavior is correct; my argument has been that pasting source text into an empty paragraph in a different style should *also* be changed to the target style. (In particular with reference to footnotes, but also applicable to everything else.) It is crucial, however, that manually applied character attributes (bold, italics, etc.) be preserved when pasting changes the style of the source text.

(In reply to William Friedman from comment #16)
> my argument has been that pasting source text into an empty paragraph in a
> different style should *also* be changed to the target style.

That wont be accepted by users. Footnotes are an exception, so I suggest to continue on bug 100018 and to file a special ticket "paragraph break in clipboard content must not change the style when pasted" (or the like).

Feel free to reopen if you disagree.

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

(In reply to Heiko Tietze from comment #17)
> (In reply to William Friedman from comment #16)
> > my argument has been that pasting source text into an empty paragraph in a
> > different style should *also* be changed to the target style.
> 
> That wont be accepted by users. Footnotes are an exception, so I suggest to
> continue on bug 100018 and to file a special ticket "paragraph break in
> clipboard content must not change the style when pasted" (or the like).
> 
> Feel free to reopen if you disagree.
> 
> *** This bug has been marked as a duplicate of bug 100018 ***

I don't understand on what basis you're asserting "that won't be accepted by users." In the thread on bug 100018 there was agreement that the current behavior -- changing the target style to the source style if the target style is empty, but changing the source style to the target style if there is even one character -- is unexpected and strange to the user. Consider the following case: I write a paragraph, say in default style or text body style or whatever, incorporating a quotation. I decide that I want to have the quotation be in quotation style. I select and cut the text, create a new paragraph and set it to quotation style. If I paste the text without typing any new character, it will reset to default or text body or whatever style. If I type a space, then it will paste as quotation style, exactly as the user expects. I cannot see any circumstance under which a user would deliberately set a style and paste text into it and *not* expect the text to be changed to the selected style (while retaining character attributes like bold and italics and whatever).

Separately, I don't know how to "file a special ticket" -- do you mean add a comment to this effect to that thread? I'm happy to do that. Thank you.

(In reply to William Friedman from comment #18)
> I cannot see any circumstance under which a user would
> deliberately set a style and paste text into it and *not* expect the text to
> be changed to the selected style (while retaining character attributes like
> bold and italics and whatever).
Simply the other way round.
I do an Enter, paragraph style is unchanged (e.g. Text Body) and I copy paste some text with a different style that I want to be retained.
Changing the behavior for your case, would break it in this case.
So I would not change it.

(In reply to Cor Nouws from comment #19)
> (In reply to William Friedman from comment #18)
> > I cannot see any circumstance under which a user would
> > deliberately set a style and paste text into it and *not* expect the text to
> > be changed to the selected style (while retaining character attributes like
> > bold and italics and whatever).
> Simply the other way round.
> I do an Enter, paragraph style is unchanged (e.g. Text Body) and I copy
> paste some text with a different style that I want to be retained.
> Changing the behavior for your case, would break it in this case.
> So I would not change it.

Yeah, I hear that. That's why I suggested (on the other bug thread) allowing users to configure which default paste behavior they want, and to add a "paste special" option that would allow selecting each individual attribute to retain and which to override. Designing for flexibility rather than having the software second guess the user, or worse, impose some presumed use case on the user, seems like a better option to me.

We discussed the topic in the design meeting. While the need is clear for footnotes and endnotes (bug 100018), we have a well-known workflow in general. What we can do is:

a) Keep the source PS not only for empty target paragraphs but also ignore all white-space: when pasting somewhere in the middle of a paragraph it is very unlikely that the source PS should be applied, so just ignoring white-space might solve the actual problem
b) Introduce a new paste special option (or a new UNO command in order to assign a shortcut) that pastes without paragraph style but not unformatted: with this option the user can decide whether the target PS is overridden or not; the current behavior of paste and paste special wouldn't change
c) Enhance the PS attributes by a flag "[ ] Override style on paste" that allows to define individually whether or not pasting formatted clipboard content should change the target PS; this solution could be used for Footnotes as requested in bug 100018

(In reply to Heiko Tietze from comment #22)
> a) Keep the source PS not only for empty target paragraphs but also ignore
> all white-space: when pasting somewhere in the middle of a paragraph it is
> very unlikely that the source PS should be applied, so just ignoring
> white-space might solve the actual problem
So if there is an paragraph with a single space, and the pasting is done at the beginning of the paragraph: ignore the space and if the pasting is done after the space, do not ignore it. (To make the trick even more specific.. ;) )

*** Bug 105550 has been marked as a duplicate of this bug. ***

*** Bug 139791 has been marked as a duplicate of this bug. ***