1. In a new text document, add a lorem ipsum text. 2. Select all (Ctrl+A), and set font size to 18. 3. Select a single word (e.g., double-click it), and apply italic direct formatting (Ctrl+I). 4. Select another word in the same paragraph (double-click it) and clear direct formatting (Ctrl+M). 5. Undo (Ctrl+Z), undo again (Ctrl+Z). Expected: all text has font size 18, not italic (since the effects of both Ctrl+M and Ctrl+I were undone, but not setting font size 18). Actual: the word that was made italic at step 3 has now font size 12. Undoing once after step 4 gives expected result, so it is likely step 5 that breaks the undo. Reproducible with current master (toward 6.4), and with LibreOffice 3.5.0rc3 Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735. Not reproducible with LibreOffice 3.5.0rc3 Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735.
Reproduced in Version: 6.4.0.0.alpha0+ Build ID: ea4f3099d6e0cf30d80caa8b2121c7a358f80fdd CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Jim, I thought you might be interested in this issue...
(In reply to Mike Kaganski from comment #0) > Not reproducible with LibreOffice 3.5.0rc3 > Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735. Oh, sorry: not reproducible with LibreOffice 3.4.0 OOO340m1 (Build:11) Is that possible to bisect in range 3.4-3.5?
(In reply to Mike Kaganski from comment #2) > (In reply to Mike Kaganski from comment #0) > > Not reproducible with LibreOffice 3.5.0rc3 > > Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735. > > Oh, sorry: not reproducible with LibreOffice 3.4.0 > OOO340m1 (Build:11) > > Is that possible to bisect in range 3.4-3.5? oldest bisection build is LibreOffice 3.5.0 Build ID: d6cde02 and it's already reproducible, so not possible to bisect this particular issue
Hi all, Here is a stab at this made by observing expected undo results after selecting all but the first or last character in a paragraph. https://gerrit.libreoffice.org/#/c/79808/ Review required and very much appreciated.
Made some test with the steps from comment 0 (in a version without patch from comment 4). Specifically, I have saved a new copy of the document after each of the steps starting after 2. For creating lorem ipsum text, I typed "lorem" then F3, so I had 4 paragraphs in the document (the last empty). After step 2, the resulting ODF contained all paragraphs having direct formatting applied at *paragraph* level; the size 18 was defined in styles under "office:automatic-styles" element, which had style:family="paragraph"; no styles there having style:family="text". After step 3, the paragraph with the modification still had size defined at paragraph level, but the italic formatting was, naturally, defined at character level (i.e., using a test:span referring to a style which family was "text"). After step 4, the edited paragraph no more had direct formatting at the paragraph level: instead, all formatting was now using several text:span elements, which referred to two character autostyles. The portion that was cleared from direct formatting was outside of the spans, i.e. having the paragraph formatting. After step 5, the modified paragraph was also free of direct formatting, and everything manual was still applied using text spans. So I believe that the problem here is that when we clear direct formatting in a span inside a paragraph having direct formatting at paragraph level, its formatting is modified in such a way that is isn't a paragraph-level formatting anymore, but a character-level formatting; and *this step is not undone* in undo, which is the reason of the bug.
I observed that undo, redo, undo results in expected results for this problem. Maybe this will help to find a real fix. Here is a patch that does undo, redo, undo for SwUndoAttr undos. https://gerrit.libreoffice.org/#/c/85195/
*** Bug 127694 has been marked as a duplicate of this bug. ***
*** Bug 132910 has been marked as a duplicate of this bug. ***
Also in Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0ceb131e964206efbb1c76a03f19d1992e2f89c7 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Dear Mike Kaganski, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug