Description: This issue is about Impress and Draw zooming to more than 1000%. (It’s only them, because the maximum zoom at Writer is 599% and in Calc is 399%.) Slide the zoom to more than 1000&, click on the zoom level number, „Zoom & View Layout“ window appears. It suggests as a variable 1000%. When you click "OK" nothing happens. Steps to Reproduce: Windows: I tested it with the portable version of LO 3.3, 4.0, 4.2, 4.3, 4.4, 5.0, 5.4 and in a normal installation (safe mode) of LO 6.001 RC1 and 6.1.0.0.alpha0+ 1. Create empty presentation (Zoom is automatically set to fit the screen, so it can be 104, 106, 107 % or else (depends on LO version)) 2. Click on a the slider in the bottom right to get a zoom that has a higher value than 1000%. -> LO will display a value like e.g. 2345% 3. Click (in old LO versions - double click) on the number. -> „Zoom & View Layout“ window appears. It suggest a value of 1000%. 4. Click on „OK“. ->Nothing happens. Zoom factor stays the same. 5. Open „Zoom & View Layout“ window again 6. Delete the „1000%“ (empty the variable field) 7. Click „OK“ -> Zoom is set to 1000% and displayed at 1000% zoom. 9. Open „Zoom & View Layout“ window again 10. Set Zoom to a higher value than 1000% (like 1500%) 11. Click “OK”. -> Zoom is set to 1500% Linux: But exists on Linux, too. But if I run LO 5.4.4.2, Impress will suggest 5% instead of 1000%. 1. Create empty presentation (Zoom is automatically set to fit the screen, so it can be 104, 106, 107 % or else (depends on LO version)) 2. Click on a the slider in the bottom right to get a zoom, that it greater than 1000%. -> LO will display a value like e.g. 2345% 3. Click on the number. -> „Zoom & View Layout“ window suggests a value of 5 % instead of 1000%. 4. Click on „OK“. ->Nothing happens. Zoom factor stays the same. 5. Open „Zoom & View Layout“ window again 6. Delete the „1000%“ (empty the variable field) 7. Click „OK“ 8. Zoom will skip to 5 % instead of 1000 %. I installed Linux Mint 18.3 MATE Sylvia. It was shipped with LO 5.1.6.2. This version suggest 1000%. But I upgraded to 5.4.4.2 and now Impress suggests 5% Fedora 27 ships with LO 5.4.4.2, that suggest 5% Following combinations suggested 1000% Elementary OS & LO 5.4.4.2 -> 1000% OpenSUSE Tumbleweed & LO 5.4.3.2 1000% Ubuntu 17.10 & LO 5.4.2.2 1000 % Actual Results: See above Expected Results: LO should adjust to the variable set in the zoom field, when I click "OK". Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: The issue is inherited from OOo. Im not an expert, but maybe a connection to this issue exists? https://bugs.documentfoundation.org/show_bug.cgi?id=108552 I attached videos, that show the 5% zoom on Linux. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Created attachment 138769 [details] 5% instead of 1000% in Fedora 27 with LO 5.4.4.2
Created attachment 138770 [details] 5% instead of 1000% in Linux Mint MATE 18.3 with LO 5.4.4.2
Yep, like you say it is a regression. I don't see the problem in 3.6.7.2 Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: 2d8f17565ebe867210f5769851d91b2e7b612a8f CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on January 27th 2018 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
Maybe this new observation helps: In LO 6 RC1, the dialog suggests a zoom of 1000%, in LO6 RC2 the dialogs suggest a zoom of 5%,
Bug already exits in the "oldest" version in bibisect-linux-64-6.0: Version: 5.4.0.0.alpha1+ Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1 CPU threads: 4; OS: Linux 4.14; UI render: default; VCL: gtk3; Locale: zh-CN (zh_CN.UTF-8); Calc: group Fedora 27 x64. (By saying "the bug", I mean the un-functioning when you click the OK button at step 4.)
(In reply to Buovjaga from comment #3) > Yep, like you say it is a regression. I don't see the problem in 3.6.7.2 > > Arch Linux 64-bit > Version: 6.1.0.0.alpha0+ > Build ID: 2d8f17565ebe867210f5769851d91b2e7b612a8f > CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; > Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded > Built on January 27th 2018 > > Arch Linux 64-bit > Version 3.6.7.2 (Build ID: e183d5b) Maybe I got things wrong, but I think, that the non-responsiveness is inherited from OOo. I can reproduce the issue in 3.3.0
Created attachment 139776 [details] Video - Issue in LO 3.3.0 Portable reproducable.
(In reply to Mike from comment #7) > Created attachment 139776 [details] > Video - Issue in LO 3.3.0 Portable reproducable. I just re-tested and 3.6.7 does not behave like that. It behaves as expected.
Created attachment 139777 [details] LO 3-6-5 -Portable-Win10-64x Issue present Weird. Issue is present with 3.6.5 Portable on Win 10 64x...
(In reply to Mike from comment #9) > Created attachment 139777 [details] > LO 3-6-5 -Portable-Win10-64x Issue present > > Weird. Issue is present with 3.6.5 Portable on Win 10 64x... I mean 3.6._4_ not 3.6.5
(In reply to Buovjaga from comment #8) > (In reply to Mike from comment #7) > > Created attachment 139776 [details] > > Video - Issue in LO 3.3.0 Portable reproducable. > > I just re-tested and 3.6.7 does not behave like that. It behaves as expected. Hmm, it seems I was wrong. I re-tested again with 3.6.7 and now I see the problem.
Dear Mike, 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
One thing ist fixed: >3. Click (in old LO versions - double click) on the number. >-> „Zoom & View Layout“ window appears. It suggest a value of 1000%. >4. Click on „OK“. >->Nothing happens. Zoom factor stays the same the other thing is not fixed >5. Open „Zoom & View Layout“ window again >6. Delete the „1000%“ (empty the variable field) >7. Click „OK“ >8. Zoom will skip to 5 % instead of 1000 %. If you delete the zoom factor variable, the zoom will skip to 5% and not 100%. Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL
(In reply to Mike from comment #13) > the other thing is not fixed > > >5. Open „Zoom & View Layout“ window again > >6. Delete the „1000%“ (empty the variable field) > >7. Click „OK“ > >8. Zoom will skip to 5 % instead of 1000 %. > > If you delete the zoom factor variable, the zoom will skip to 5% and not > 100%. Well, in a way this is to be expected as you are basically telling it to zoom to 0%, while the minimum is 5%. Let's ask the design team, if they think the behaviour should be changed. If not, we will just close this as WFM.
Yes, 5% is the minimum.