Created attachment 180067 [details] Sample PPTX deck How to repeat: 1. Open sample presentation 2. Enter presentation mode 3. <Right> moves to slide 2. 4. <Right> moves to slide 3. 5. <Left> moves to slide 2. 6. <Left> SHOULD move to slide 1. <Left> DOES move to slide 3. 7. <Left> moves to slide 2. 8. <Left> finally moves to slide 1. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: e9c50fbbc3b07ef927d133da9cf2395c55611e0f CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US
I'd completely change this report, if you agree. No repro for reported. Slide 2 advances to 3 automatically, that may confuse. But I have crash with GTK3 after I advance to slide 2.
Oh, another quirk here: if I try to set 1st slide to advance automatically, to automate bibisect, my MSO 2016 doesn't obey that and so LO also.
commit 59e9d50757e55b1da148976b86adb8db3ebfc811 Date: Mon Mar 28 15:08:12 2022 +0200 author Stephan Bergmann <sbergman@redhat.com> Drop support for OpenGL denylist on X11 and that should explain why crash depends on the system.
(In reply to Timur from comment #1) > I'd completely change this report, if you agree. > No repro for reported. Slide 2 advances to 3 automatically, that may confuse. > > But I have crash with GTK3 after I advance to slide 2. Hi Timur, I can now reproduce this most of the time, thanks to your hint regarding the automatic advance from slide 2 to 3. I had, by chance, timed things correctly (or badly, depends on how we look at it): 1. Open sample presentation and enter presentation mode. 3. <Right> to move to slide 2. 4. Wait until the presentation automatically moves to slide 3. 5. <Left> to move to slide 2. 6. Wait about half a second, maybe only a third, and press <Left> again. This is now too late and the the presentation will advance to slide 3. 7. Now, regardless of how often you hit <Left> the presentation is stuck on slide 3. Note: If this does not happen, repeat steps 5 and 6 and *reduce* the delay before hitting <Left> in step 6 a bit. Note: If instead step 6 brings you back to slide 1 start again from step 3 and *increase* the delay before hitting <Left> in Step 6 a bit. Can you reproduce this now? Do you want to create a separate bug for the issue you encountered, or do you prefer to use this one and for me to create a new one?
No repro Comment 4 in Windows, I can't test in Linux (new report in See Also).
(In reply to Gerald Pfeifer from comment #4) > 1. Open sample presentation and enter presentation mode. > 3. <Right> to move to slide 2. > 4. Wait until the presentation automatically moves to slide 3. > 5. <Left> to move to slide 2. > 6. Wait about half a second, maybe only a third, and press <Left> again. > This is now too late and the the presentation will advance to slide 3. > 7. Now, regardless of how often you hit <Left> the presentation is > stuck on slide 3. > > Note: If this does not happen, repeat steps 5 and 6 and *reduce* the > delay before hitting <Left> in step 6 a bit. > > Note: If instead step 6 brings you back to slide 1 start again from > step 3 and *increase* the delay before hitting <Left> in Step 6 a bit. Reproduced on Linux with all VCL backends, but not on Windows. The timing is indeed very tricky. Might be bibisectable, but the delicate timing makes it a nightmare. Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f1d00da1bb16330bef9316a3e4f04506f9bb862f CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Jumbo Built on 10 January 2023