Bug 52391 - EDITING: "Record/track changes": Rejected changes in character attributes are accepted instead of rejected
Summary: EDITING: "Record/track changes": Rejected changes in character attributes are...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: BSA target:6.3.0
Keywords: dataLoss
: 91838 (view as bug list)
Depends on:
Blocks: Track-Changes
  Show dependency treegraph
 
Reported: 2012-07-23 11:51 UTC by wojciech
Modified: 2019-06-20 11:22 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description wojciech 2012-07-23 11:51:39 UTC
Problem description: 
In "Record changes" mode, if you change text attributes and then wish to reject this change - the change is apparently rejected but the attributes stay changed.

Steps to reproduce:
1. Turn on the "Record changes" option;
2. Change any of the text attributes (color, highlighting, font, size, style etc.);
3. Reject this change

Current behavior:
The change does take effect although it is apparently rejected (i.e. it is not recorded as a "change").

Expected behavior:
The formatting should be reverted to what it was like before making the change.

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Comment 1 stfhell 2012-11-11 18:49:42 UTC
I can confirm this bug for LO 3.3.4, 3.5.4.2, 3.6.2.2 and 3.7.0.0.alpha0+ (Build ID: 52faa1) on Ubuntu 12.04; and for OOo 3.1.1. When attribute changes are rejected, LO really accepts them.
Comment 2 bfoman (inactive) 2013-03-06 12:40:56 UTC
NEW per comment 1.
Comment 3 QA Administrators 2015-10-14 19:56:25 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2015-12-02 10:59:50 UTC
Still repro.

Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+
Build ID: a7c3a2a9be83686657c06f37d521f9f6d2004ddd
Threads 4; Ver: Windows 6.1; Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2015-11-28_04:39:18
Locale: fi-FI (fi_FI)
Comment 5 Robinson Tryon (qubit) 2015-12-14 06:08:42 UTC Comment hidden (obsolete)
Comment 6 Lun 2018-11-29 08:38:37 UTC
Still exists in version 6.3.0.0

Problem description: 
In "Record changes" mode, if you change text attributes and then wish to reject this change - the change is apparently rejected but the attributes stay changed.

Steps to reproduce:
1. Open a documented to be changed
2. Edit >> Track Changes >> Record(Ctrl+Shift+E)
3. Change any of the text attributes (color, highlighting, font, size, style etc.);
3. Edit >> Track Changes >> Reject All

Current behavior:
The change does take effect although it is apparently rejected (i.e. it is not recorded as a "change").

Expected behavior:
The formatting should be reverted to what it was like before making the change.

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
Calc: threaded  
      
OS:Windows 10 Pro.
Comment 7 Commit Notification 2019-01-25 14:13:12 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/a8a3928bd3614e52edc0a4df6f67ce53e787905c%5E%21

tdf52391 don't accept format-only changes secretly

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2019-01-29 19:41:28 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/9c4eef7d809ad7d283860c7b47b0f561aa240906%5E%21

tdf#52391 reject/clear formatting of format-only changes

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 László Németh 2019-01-29 19:50:43 UTC
Rejected changes in character attributes aren't accepted any more, but the recent rejection is still an approximation, using clearing direct formatting in the area of the format-only tracked changes.

I close this issue, keeping Bug 58813 for the remaining problems.

Description of the previous commit:

tdf#52391 reject/clear formatting of format-only changes

Format-only changes had 1) disabled (in Manage Changes
dialog window) or 2) bad rejection (Track Changes toolbar
icons and Edit->Track Changes menu item functions
"Reject"/"Reject All" resulted acception of the tracked
format-only changes instead of rejection).

Because format-only changes haven't had real rejection
support, yet, this commit 1) adds an often useful
reject-like function in the Manage Changes dialog window:
instead of disabling Reject/Reject All, now these buttons
clears direct text formatting in the area of the tracked
format-only changes. Because this may be not a rejection
(ie. the original text can contain direct text formatting),
the labels of the button warn about it: "Reject/Clear
formatting" and "Reject All/Clear formatting".
Note: "Reject All" still rejects only
insertions/deletions at (now first) pressing,
as from commit a8a3928bd3614e52edc0a4df6f67ce53e787905c.

2) Icons and menu items "Reject"/"Reject All" clear
direct text formatting in the areas of the tracked
format-only changes. Note: this is still not ideal,
but it can help to avoid of unintended direct
text formatting until implementing upcoming ODF 1.3
change tracking.
Comment 10 László Németh 2019-06-20 11:21:11 UTC
*** Bug 91838 has been marked as a duplicate of this bug. ***