Bug 58813 - Can't reject format changes in "Accept or Reject Changes" dialog or via context menu
Summary: Can't reject format changes in "Accept or Reject Changes" dialog or via conte...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 76772 (view as bug list)
Depends on:
Blocks: Track-Changes
  Show dependency treegraph
 
Reported: 2012-12-27 18:11 UTC by hessijames
Modified: 2019-07-03 11:05 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
An example file to demonstrate the problem (10.94 KB, application/vnd.oasis.opendocument.text)
2012-12-27 18:11 UTC, hessijames
Details

Note You need to log in before you can comment on or make changes to this bug.
Description hessijames 2012-12-27 18:11:28 UTC
Created attachment 72195 [details]
An example file to demonstrate the problem

LibreOffice keeps track of format changes (bold, font size, etc.) but it seems impossible to reject those changes.
In the "Accept or Reject Changes" dialog the "Reject" button is disabled when a "Formats" change is selected but there are still two ways to try it anyway.
Either by right-clicking on the text you changed in the main window and selecting "Reject" from the context menu. Or by selecting a non-"Formats" change in the "Accept or Reject Changes" dialog and clicking on the "Reject All" button.
The effect is the same, LibreOffice looses track of the format changes but doesn't change the text to it's original state.

I created a small example file, I hope you see what I mean.
Comment 1 Jorendc 2012-12-27 22:43:30 UTC
Thanks for reporting!

I can confirm that using Mac OS X 10.8.2
LibreOffice 4.1.0.0.alpha0+ (Build ID: 699132c269a6c6d9e815fc582e2e6a106e46923)
TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-27_01:05:51
Comment 2 Jorendc 2012-12-27 22:49:15 UTC
I can also reproduce it using the oldest LO version I have installed on Mac OSX.
LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b

So, I changed this bug to this version (instead of LO 4.0 branch).
Comment 3 Kumāra 2013-12-31 07:26:20 UTC Comment hidden (no-value)
Comment 4 Kumāra 2014-01-01 04:31:16 UTC
I'm beginning to find this annoying. It's bothersome when there's already character formatting before the recording formatting is made. So, to circumvent this bug by clearing direct formatting (the only way I know how at this point), all formatting is cleared, so that I've to redo the original ones. Eesh...

So, I'm elevating the importance to major.
Comment 5 Kumāra 2014-01-01 07:07:15 UTC
Correction: "Clear Direct Formatting" doesn't work. I've to select, cut and paste as RTF. This clearly deserves a "major" label.
Comment 6 Joel Madero 2015-05-02 15:43:37 UTC Comment hidden (obsolete)
Comment 7 hessijames 2015-05-02 16:32:04 UTC
Tested it with libreoffice 4.4.2.2 on opensuse 13.2, bug still exists without any behavioural changes.
Comment 8 Timur 2018-04-16 09:45:31 UTC Comment hidden (me-too)
Comment 9 Timur 2018-04-16 09:49:03 UTC
With 6.1+:
I. In "Accept or Reject Changes" dialog the "Reject" button is disabled when a "Formats" change is selected (this bug).
II. Right-clicking on the text you changed and selecting "Reject" from the context menu is possible but behaves wrong: removes track change info but leaves the change (Bug 52391). 
III: Selecting a non-"Formats" change in the "Accept or Reject Changes" dialog and clicking on the "Reject All" button gives similar result as II., change remains (Bug 52391).
Comment 10 QA Administrators 2019-04-17 02:58:19 UTC Comment hidden (obsolete)
Comment 11 László Németh 2019-06-20 11:25:11 UTC
*** Bug 76772 has been marked as a duplicate of this bug. ***