This report is both a bug(s) and an enhancement request. The basic bug: If you change a style from from the style editor any change you make can not be undone by the icons. Steps: 1. Create a blank writer document. 2. Modify a child style (for example Footer) by making any change (for example change the font to 20pt). 3. Select "Apply". 4. Go to the "Organizer" tab of the dialog and notice that "Contains" field is blank (THIS IS BUG #1, which I can confirm on WinXP32 right now). As the "Apply" button is new to LO3.5 I don't think I would call that a regression. 5. Now select "OK" or "Cancel". 6. Modify that child style again (i.e. Footer). 7. Go to the "Organizer" tab. Note that "Contains" field has the change(s) you made (i.e. 20pt font size). 8. Close the dialog selecting "Cancel" 9. Note that the undo icon does not have record of this change (THIS IS BUG #2). 10. Go to the "Edit" menu and select "Undo: Change style: Footer". This will reset the style change that was made, which is correct functionality (fixed from LO3.4). If you have a style that has been changed from the parent there does not, AFAICT, appear to be a method to revert back to parent (other than undo which does not help you if editing an previously saved document). If I say have in the past changed the font size of Footer to 20PT and Default is 12PT there is no way to relink the font size back to the the "Linked with". I can manually change back to 12PT it does not reestablish the link. So this is the ENHANCEMENT request (there maybe better implementations but here is one example): Next to every items in the "Contains" field have a "x" in a circle that you could click on it to reset that items link back to the parent in the organization. For example it would read: "(x)Western text: 20pt + (x)0.0 inch + (x)Indent left 0.2inch, First line..." whereever (x) is an "x" in a circle and if you click on it that link is reset back to parent and item is removed from the list. An alternative implementation is to program item level resets for each item on all the tabs (this seems like more coding to me).
Thanks for bugreport and new idea Bug slightly resembles this: Bug 47379 - Inserting then editing a footnote gives unwanted results if Apply is selected before OK May be they have one source. Idea: > Next to every items in the "Contains" field have a "x" in a circle Is very interesting. Or do all records clicable and context menu with item "Delete". Or/and highlight corresponding places in all another tabs for users can easily see which changes applied to style.
Hi skiani, Is set this for new for the Undo part. I noticed that somewhere in between 3.5 and 4.0 things changed. When I change the font of a style in 3.5 and hit Ctrl-Z afterwards, I have the original font back. Not so in 4.xx Have to find out where that regression started. Also, from your report, I understand that some changes react on undo and others do not..? For the feature request: I think that chosing Reset or Standard on a cetain tab, bings bakc the default for that tabs settings, including the link to the parent style. Seldom use it. Coudl you pls do some checks here :) thanks a lot, Cor
cannot reproduce the problem in comment #2, works fine here: 1. enter text and select 2. open stylist 3. apply "Footer" para style 4. modify "Footer" 5. change Font, OK 6. Undo 7. modify "Footer", old font is back (also in document view) btw this appears to be a different problem (no Undo on OK/Apply) than what is in the description, so even if i'm doing it wrong please open a new bug for that. regarding description: > 8. Close the dialog selecting "Cancel" > 9. Note that the undo icon does not have record of this change (THIS IS BUG #2). of course if you cancel the dialog then no changes are made, so why do you expect an Undo action for that? Undo should only be created on clicking Apply or OK, which is working. > 2. Modify a child style (for example Footer) by making any change (for example change the font to 20pt). > 3. Select "Apply". > 4. Go to the "Organizer" tab of the dialog and notice that "Contains" field is blank (THIS IS BUG #1, which I can confirm on WinXP32 right now). so the Organizer tab is updated right when changing the Font, before clicking "Apply" (i.e. it apparently displays the content of the dialog, not the current content of the style), but clicking "Apply" appears to clear it. agree it's not a regression if older versions have no "Apply" button.
(In reply to comment #3) > cannot reproduce the problem in comment #2, works fine here: > > 3. apply "Footer" para style > [...] > 7. modify "Footer", old font is back (also in document view) > [...] It seems it works fine indeed _except_ for Text body (4.0.5.2 / 4.1.1.2) Stupid I did not notice that.
Restricted my LibreOffice hacking area
** 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 (4.4.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-05-02
(In reply to skiani from comment #0) > This report is both a bug(s) and an enhancement request. The basic bug: > > If you change a style from from the style editor any change you make can not > be undone by the icons. Steps: > > 1. Create a blank writer document. > 2. Modify a child style (for example Footer) by making any change (for > example change the font to 20pt). > 3. Select "Apply". > 4. Go to the "Organizer" tab of the dialog and notice that "Contains" field > is blank (THIS IS BUG #1, which I can confirm on WinXP32 right now). As the > "Apply" button is new to LO3.5 I don't think I would call that a regression. Contains was not blank after Apply. Tried with Text body, too. > 5. Now select "OK" or "Cancel". > 6. Modify that child style again (i.e. Footer). > 7. Go to the "Organizer" tab. Note that "Contains" field has the change(s) > you made (i.e. 20pt font size). > 8. Close the dialog selecting "Cancel" > 9. Note that the undo icon does not have record of this change (THIS IS BUG > #2). > 10. Go to the "Edit" menu and select "Undo: Change style: Footer". This will > reset the style change that was made, which is correct functionality (fixed > from LO3.4). Confirmed undo button, adjusted summary, priority and severity. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58 Locale: fi-FI (fi_FI)
** 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.1.5 or 5.2.1 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 helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Still reproducible in Version: 6.2.0.0.alpha0+ Build ID: dbfa1c452fd9d02330cb3ec5bf2fd4f2c7782d1a CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded but not in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 nor in Apache OpenOffice 4.1.3
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=c52ba433491afbca70aa1977a624c795bdd5b9ef..099198a4224778fe6e43f5dc13b5b9b1b4dc828c
*** Bug 88921 has been marked as a duplicate of this bug. ***
*** Bug 77325 has been marked as a duplicate of this bug. ***
Andreas B. 2016-11-18 21:20:16 CET, from bug 88921: In my Opinion this is a Bug, because it's working sometimes. I list here, what is working and what not. If there would be nothing working, I would say it's an enhancement, but with this list, I would say its a Bug. (I didn't test every setting, this is only an Overview) I changed the importance to "normal" Working: Calc: Change name of a Style Changing Parent Change Font Change Font Effects Aligment Border Background Cell Protection Draw: Nothing found, not all Tested Writer: Change highlighter Color Indents and Spacing Alignment Text Flow Font Font effects Position Outline and Numbering Gradient Transparency Border Not Working: Calc: Tab "Numbers" changing Draw: Background Line Change name of a Style Change Parent of a Style Font Transparency Writer: Change name of a Style
*** Bug 90425 has been marked as a duplicate of this bug. ***
Hi all, while looking at bug 118384 I noticed the bug reported here. I have come up with a patch that addresses the title issue of this report about the undo command button not being activated when a style is added or modified. https://gerrit.libreoffice.org/#/c/76146/
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/ed882d693f37779e3a09641e7cd43b7a925d2312%5E%21 tdf#47807 Invalidate bindings to Undo Redo It will be available in 6.4.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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/3c7efab4e72d6f044a3ace34c06d2dfdfafbe42b%5E%21 tdf#47807 Invalidate bindings to Undo Redo It will be available in 6.4.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.
Dear skiani, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is fixed, at least the problem described in the summary. Tested in Version: 7.3.1.0.0+ / LibreOffice Community Build ID: d036ea9651c05a2a50794bc5c0ee7ea54708ad6a CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Ubuntu_20.04_x86-64 Calc: threaded Closing as Resolved Fixed. If another issue mentioned in the comments is still there, please open a new bug report. Best regards. JBF