Bug 104920 - Clone Formatting in Writer Does Not Properly Copy Attributes Sometimes
Summary: Clone Formatting in Writer Does Not Properly Copy Attributes Sometimes
Status: RESOLVED DUPLICATE of bug 71481
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2016-12-25 09:18 UTC by mcree762
Modified: 2017-10-28 18:25 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Example Document Where The Issue Occurs (10.27 KB, application/vnd.oasis.opendocument.text)
2016-12-25 09:39 UTC, mcree762
Details
Assertion failed dialog (67.18 KB, image/jpeg)
2017-01-07 18:39 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mcree762 2016-12-25 09:18:56 UTC
Description:
When I use the clone formatting button to copy attributes (generally I just use it to copy the font size and font type), sometimes the attributes will not copy from the selected text. 

This is not normal behavior, as most of the time the clone formatting works properly, in similar situations. Furthermore, I found a way to fix this issue, implying that this is a bug.

In cases where it does not work properly, here's what seems to fix it. First, (on the text you want to copy the formatting from), you manually hit enter on the attributes, in the formatting toolbar. You should do this for all of the attributes you want to transfer, that are not transferring properly right now, to that problem line of text. 

For example, go to the formatting toolbar and hit enter on the text size and font type. (The attributes displayed in the toolbar will already be accurate, you just need to hit enter to "re-set" them.)  After re-assigning the attributes the problem will be resolved. The font formatting will properly copy to the problem text in the future, with no further issues.

Note that when this problem originally occurs, sometimes some attributes will copy fine. For instance, before re-entering the attributes, the clone formatting button might copy the text font but not the font size, to the problem line of text. 

Thank You!

Steps to Reproduce:
1.Click on text where the formatting needs to be copied from
2.Select the "Clone Formatting" button
3.Highlight the text to be formatted

Actual Results:  
Sometimes the attributes do not copy properly. 

Expected Results:
Font size and font type should have been copied to the text.


Reproducible: Sometimes

User Profile Reset: No

Additional Info:
-Occurs in Linux Mint 18 and Windows 7 using 5.2.3.3 (64 bit)
-Occured in the previous versions of Libre Office Writer (version 5.?.?)
-This issue does not occur all of the time. It happens sporadically but regularly and for a long enough time, to know there is a issue here. A video or example file can be provided.


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Comment 1 mcree762 2016-12-25 09:39:28 UTC
Created attachment 129936 [details]
Example Document Where The Issue Occurs
Comment 2 Joel Madero 2016-12-26 16:48:38 UTC
Given that user has said he or she found a way to fix the issue (a workaround?) lowering to minor.

Minor: Can slow down but will not prevent high quality work.
Comment 3 Buovjaga 2017-01-01 21:10:26 UTC
Yep, confirmed with the document. I had to highlight the text and reassign the 12 pt font before cloning worked.

However, in 3.6.7.2 I did not have to do this. It worked right away.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: fc0d4e6bc43d5f982452df07930f5ecf5927ad22
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on December 31st 2016

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)
Comment 4 Terrence Enger 2017-01-03 19:11:39 UTC
My attempt to reproduce this led to tdf#105077 "assertion in SwRegHistory::InsertItems".  Perhaps that is how a dbgutil build reports the problem reported here.
Comment 5 Aron Budea 2017-01-07 18:39:25 UTC
Created attachment 130248 [details]
Assertion failed dialog

Works in 3.6.0.4, doesn't work in 4.0.0.3 / Windows 7. Adjusting earliest affected version.

Also confirming assertion failed error in a dbgutil master build (87fce022c65c1d2aed1ca59967137d77d936043c). See attached screenshot.
Comment 6 Terrence Enger 2017-01-11 14:25:54 UTC
I see that the assertion reported in bug 105077 is fixed, but I still
see this bug in daily Linux dbgutil bibisect repository version
2017-01-11.  So, I am changing the bug summary to remove mention of
the assertion.

Perhaps the comment in commit db4badfc, fixing bug 105077, is a hint
for this bug:

    // tdf#105077 even worse, node's set could cause
    // nothing at all to be inserted
Comment 7 Terrence Enger 2017-01-11 14:38:04 UTC
Aron,

Where is the "Clone Formatting" menu option option that you mention in
comment 5?  I do not see it in my old versions, like bibisect-42all
version oldest.
Comment 8 Aron Budea 2017-01-14 00:34:22 UTC
Look for a paintbrush on the toolbar. It's called Format Paintbrush in old version.
Comment 9 Terrence Enger 2017-01-14 18:56:21 UTC
Thank you for that pointer, Aron.

I see that the repository bibisect-41max version oldest already has
the bug
Comment 10 Aron Budea 2017-02-09 02:00:17 UTC
Seems to be a duplicate of bug 82725.

*** This bug has been marked as a duplicate of bug 82725 ***
Comment 11 Xisco Faulí 2017-10-28 18:25:41 UTC

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