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
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.
NEW per comment 1.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.1 or preferably 5.0.2.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-10-14
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)
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]
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.
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.
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.
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.
*** Bug 91838 has been marked as a duplicate of this bug. ***