Description: Change a slide in Presenter view if press close button in all slide view Steps to Reproduce: 1.Open Presenter View (With second monitor) 2.Select 2 or 3 or 4 slide 3.Press Slides button 4.Press Close button Actual Results: If press close button it returns to 1st slide. Mouse point will select the 1st slide with close button at the same time Expected Results: Pressing of close button shouldn't shange a slide Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 6.3.2.2 Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US Calc: threaded
I confirm with LO 6.3 tested in Linux Mint. Worked before, tested with Lo 5.4 so regression. I didn't test Windows. I can't test LO master because there's even worse regression tested in Alpha1, presenter view doesn't start at all.
Also worked with 6.2.8.2 so regression from 6.3.
(In reply to Timur from comment #1) > I confirm with LO 6.3 tested in Linux Mint. Worked before, tested with Lo > 5.4 so regression. I didn't test Windows. > I can't test LO master because there's even worse regression tested in > Alpha1, presenter view doesn't start at all. The master one is reported in bug 128166 and it's already fixed in https://cgit.freedesktop.org/libreoffice/core/commit/?id=6855e41d308e14bc207d84953ff6df7e4c842434
Samuel, please take a look at this regression. # bad: [d69ce43ec33c664199e197a216c76232d3d182ad] source a955330e052cc12c622982f38c5f5d138484013a # good: [cbe79d197e743d9c38dd1c13c781212e7834bfab] source a20a2d7e0d28658f2d9089da076961a599833a28 git bisect start 'master' 'oldest' # good: [7af8c7915fcf485485c67febdb6686159afa9d3d] source e9c9848d30c90bd430193dd1b408db6889400063 git bisect good 7af8c7915fcf485485c67febdb6686159afa9d3d # bad: [ca2c11c3802cfcba36d9909d799e9f2c7823cb62] source 1369a16651aba967c157f41793657369c094df5a git bisect bad ca2c11c3802cfcba36d9909d799e9f2c7823cb62 # good: [50f298c741a8ba46ebb9902973ba505a0ac5ac3d] source 9683627f01d988be7958ee9a0311e20633598971 git bisect good 50f298c741a8ba46ebb9902973ba505a0ac5ac3d # good: [108ddc87c3c0752c33516afccd649ab0ca602ca6] source 0013f21ecd918e0541f165c3526a58f42dd75481 git bisect good 108ddc87c3c0752c33516afccd649ab0ca602ca6 # bad: [aecede22f50cc0c8fa01a3e55b75b9e004ae52a4] source b56678eaf231d4e8998aef928ab314918c5bd187 git bisect bad aecede22f50cc0c8fa01a3e55b75b9e004ae52a4 # good: [a9bc5f0600a1f1cb6139ac5abfbc2ad9b8a43b26] source 8d65b2bafa1ee000b2722c3c5e6d45a62b74c196 git bisect good a9bc5f0600a1f1cb6139ac5abfbc2ad9b8a43b26 # bad: [e6bffea9f729d1c5a0d010d290fab4e48e4c121c] source 4ea0059bca6dd84f10abcf52f6d6b81c1afec397 git bisect bad e6bffea9f729d1c5a0d010d290fab4e48e4c121c # good: [032a7cb44db440b80659c4b12374fe3e89cad4ec] source 8cd78aef23a5fe411ed19cce502dca9a3043c551 git bisect good 032a7cb44db440b80659c4b12374fe3e89cad4ec # bad: [e10670c8cbbf494ed45075ca6024551f3be31863] source 185e01c015528cafbddcda5dfdabf816ce8be20e git bisect bad e10670c8cbbf494ed45075ca6024551f3be31863 # good: [6a868a97bda9bb46ea8ad4fdfdae29b7dfb14e29] source 976ad787b5243d3365a829cb0ddd2f4e8eddd0c6 git bisect good 6a868a97bda9bb46ea8ad4fdfdae29b7dfb14e29 # bad: [717e223f7d25c3ff69c19ccd96b939c45e3a07c0] source 73482f5e8742cc9fce32de1fc660059aae2a9583 git bisect bad 717e223f7d25c3ff69c19ccd96b939c45e3a07c0 # good: [53093289f1bcba93fd8d92e8dab5668570991703] source c650217cc543080928a26de4bfc07ebb0be5c6ca git bisect good 53093289f1bcba93fd8d92e8dab5668570991703 # bad: [266aa9007a66b26f34d3438e4ac92c6401135bce] source 6f43902b12dd36fa2b69401065df198ef9ffdb09 git bisect bad 266aa9007a66b26f34d3438e4ac92c6401135bce # first bad commit: [266aa9007a66b26f34d3438e4ac92c6401135bce] source 6f43902b12dd36fa2b69401065df198ef9ffdb09 https://gerrit.libreoffice.org/plugins/gitiles/core/+/6f43902b12dd36fa2b69401065df198ef9ffdb09 commit 6f43902b12dd36fa2b69401065df198ef9ffdb09 [log] author Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Wed Apr 10 11:21:32 2019 +0200 committer Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Wed Apr 17 08:20:26 2019 +0200 tree ceec26c88e04371cf7acff07fbf023afb1bba3c0 parent c650217cc543080928a26de4bfc07ebb0be5c6ca [diff] tdf#122920 Send UNO mouse events to parent window listeners as well When user registers a mouse listener to a window, he expects to receive mouse events when a user clicks in somewhere in that window, even if it's technically a widget inside that window Change-Id: Ie6d3f8b140e4a5b516051014282b43775ecec59e Reviewed-on: https://gerrit.libreoffice.org/70512 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8eba06afac375db28022d320d19943d8a129c436 tdf#127921 Don't change slides when clicking in Slide sorter view 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.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/18ff6840185758145c1620c700125022c34ad107 tdf#127921 Don't change slides when clicking in Slide sorter view It will be available in 6.3.4. 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.
Hello Samuel. Sorry but I still reproduce this with Linux master updated today. If I have 4-pages presentation and use presenter and at slide 3 (with next slide being 4) click on Slides, Slide overview doesn't mark 3 as it should but 4 - meaning it marks the Next slide instead of current one. On Close I still go back to 1, which is the same as bug reported.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/aadc7ee973c1f28a0e17d551fef6b76e015a28ef tdf#127921 Revert mouse/key listeners to original state 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.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/ec0df4a5049709dede6a9c92ed57b29e398ff737 tdf#127921 Revert mouse/key listeners to original state It will be available in 6.3.4. 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.
*** Bug 127012 has been marked as a duplicate of this bug. ***
Hi Timur, Could you please confirm this issue is fixed now ?
It's OK again. I didn't test before because it's a revert.
*** Bug 128988 has been marked as a duplicate of this bug. ***
*** Bug 129125 has been marked as a duplicate of this bug. ***
Now I think it depends on close button on presenter view. And really depends on part of this close button. When I try to press this button on top margin it works normal. Then, if I move the cursor to the bottom of the closing button, the first slide is highlighted. In this situation, when you click the close button, the first slide is turned on. It's really hard to explain.
inmyplay, please make a screencast if possible.
(In reply to inmyplay from comment #15) > Now I think it depends on close button on presenter view. And really depends > on part of this close button. When I try to press this button on top margin > it works normal. Then, if I move the cursor to the bottom of the closing > button, the first slide is highlighted. In this situation, when you click > the close button, the first slide is turned on. It's really hard to explain. Please, create a follow-up bug report and let's keep this one as RESOLVED FIXED
*** Bug 128868 has been marked as a duplicate of this bug. ***
*** Bug 128804 has been marked as a duplicate of this bug. ***
*** Bug 129152 has been marked as a duplicate of this bug. ***
*** Bug 129684 has been marked as a duplicate of this bug. ***