Description: When choosing the "empty" layout for a slide in iOS (no title, no content), the slide disappears and becomes transparent. Steps to Reproduce: 1. Create a presentation using impress on iOS 2. Select a slide in the slide preview 3. Open the sidebar and click on the "empty" layout (the first one in the list) Actual Results: The slide disappears / becomes transparent but is still there. Expected Results: The slide shoud not disappear / should not become transparent. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 155392 [details] Printscreen showing the issue
Moving to NEW
Created attachment 155409 [details] Screenshot Sorry, can't reproduce in 4.1.69. Not with a freshly created presentation (as in the screenshot), and not after opening an existing one either.
In fact, even in desktop LibreOffice, it is fairly unclear to me what the "empty" layout is supposed to do. As far as I see, selecting that never changes anything in how the slide appears. If it has a two-column layout for instance, switching to the "empty" one does nothing, the slide looks exactly like before. If the slide has the default (?) single-column layout, switching to the "empty" one does nothing either.
Actually, Aron tells me that what you describe is exactly what the "empty" layout is supposed to do;) It is supposed to make the slide empty.
It seems to me that the behaviour when changing layout for existing slides is somewhat random and counter-intuitive even in desktop LibreOffice; possibly the layout selection functionality was designed to be used only when creating slides. When used to change the layout of existing slides, it sometimes might work in a sane way, but often not. This is a cross-platform problem, not specific to the iOS app.
Anyway, please test in 4.1.69. At least for me, it works as you expect in your initial comment. Whether that is what the designers of the functionality intended I don't know.
Thanks a lot Tor for the investigation and your comments. I still believe that there's something fishy here. I test with 4.2 (27) and what the "empty" layout in my opinion should do is, removing the "content frames" (like the frame/box with the "title" and the frame/box with the "main content"). What it actually does, is "hiding" the entire slide (or let's maybe call it "make it invisible"). I believe the following "facts" support my opinion: * choose the "title + main content" layout (the second one in the sidebar list) * set the background color of the slide to a color (e.g blue) * select the "title frame/box" hit the backspace key on the HW keyboard * select the "main content frame/box" hit the backspace key of the HW keyboard Result: the slides "vanishes" - IMHO the "slide canvas" with the blue background should still be visible. Now do the same thing again, but put a picture on the slide. * choose the "title + main content" layout (the second one in the sidebar list) * set the background color of the slide to a color (e.g blue) * add a random picture to the slide * select the "title frame/box" hit the backspace key on the HW keyboard * select the "main content frame/box" hit the backspace key of the HW keyboard Result: the slides stays. In my humble opinion, the "canvas" should not disappear if a user removes the content "frames". But I might be wrong here - happy to understand why this should be the way how it is. Maybe Aron has some insights here? I'll add a video.
Created attachment 156730 [details] Video demonstrating the issue See how the slide "vanishes" at second 13 Then see how it does not "vanish" as soon as a picutre is on the slide at second 46. Hope this helps to understand the issue.
Dear Nicolas Christener, 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
iOS issues are tracked on GitHub now: https://github.com/CollaboraOnline/online/issues/3927