Description: On LibreOffice Impress' standard toolbar, two buttons named "Master slide" and "Display views" sometimes do not have their states updated appropriately, when user enters and exits master slide view. Steps to Reproduce: It's better to test this on a blank presentation in Impress. 1. Make sure you have the standard toolbar shown, with both "Master slide" and "Display views" buttons. 2. Click "Master slide" button on the standard toolbar. 3. Click "Close Master View" button on the Master View toolbar. 4. Click the "Display View" button on the toolbar and select "Master Slide" on the opened menu. 5. Click "Close Master View" button again on the Master View toolbar. Actual Results: After step 2, the "Master slide" button on the toolbar does not go to the "selected"/"pressed" state, and "Display View" button still shows a "Normal slide" icon. After step 3, the "Master slide" button might remain on the pressed state, despite the Master View being closed. After step 4, although the icon on "Display View" changes appropriately, the "Master slide" button might not go to the "checked"/"pressed" state. Expected Results: After step 2, the "Master slide" button should go to pressed state (i.e. visually appear to be pressed or selected), and "Display View" icon should change to reflect we are editing Master Slide. After step 3, both "Master slide" button state and "Display View" icon should revert to normal (i.e. unselected state and "normal" slide icon). After step 4 should behave like after step 2. After step 5 should behave like after step 3. Reproducible: Sometimes User Profile Reset: No Additional Info:
*** This bug has been marked as a duplicate of bug 118363 ***
This is not duplicate of 118363! Mine is about UI issue on the toolbar, and nothing to do with the slideshow.
(In reply to Explorer09 from comment #2) > This is not duplicate of 118363! Mine is about UI issue on the toolbar, and > nothing to do with the slideshow. Indeed. Sorry for that. Sometimes we have vandal doing senseless changes, and he was one of them. Apologies
(In reply to Explorer09 from comment #2) > This is not duplicate of 118363! Mine is about UI issue on the toolbar, and > nothing to do with the slideshow. Sorry about that, we have a vandal problem. I confirm all expect this: "After step 3, the "Master slide" button might remain on the pressed state, despite the Master View being closed." I don't understand how it "might remain" in a pressed state, when it did not go to pressed state in the first place. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 4600b07c1d787f959618d9ecf54161e4ea4ffa61 CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on June 28th 2018
(In reply to Buovjaga from comment #4) > > I confirm all expect this: > > "After step 3, the "Master slide" button might remain on the pressed state, > despite the Master View being closed." > > I don't understand how it "might remain" in a pressed state, when it did not > go to pressed state in the first place. For the demo in "Steps to Reproduce" it won't go the pressed state, but if you select or edit some Master Slide elements after the step, it might go to pressed state. Because I can't say which exact condition will make the button appear pressed, I used the word "might" here. Sorry for unclear wording.
Dear Explorer09, 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 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: 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 issue is still present on master. Like this looks very closes to this issue https://bugs.documentfoundation.org/show_bug.cgi?id=132816 that I've already patched, I take the problem in charge.
Dear Pierre Marty, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
Hi, Please forgive me for the delay. As I said before, that bug as been duplicated by: https://bugs.documentfoundation.org/show_bug.cgi?id=132816 As this request is for an older version of LO, which one should I "mark as duplicate" ? Thanks,
It's fine to close older reports as dupe sometimes, thanks for the update *** This bug has been marked as a duplicate of bug 132816 ***