Description: Open 2 presentations (libreoffice impress) in plasma (tried in 5.21 version on Arch Linux) one in monitor 1 and one in monitor 2. Passing from sheet 1 to sheet 2 in monitor 1 also makes impress change the viewd sheet in monitor 2 (and viceversa). It happends randomly but it's quite annoying if you are trying to compare and combine the 2 presentations. Steps to Reproduce: 1.open 2 presentations in 2 different screens 2.navigate through sheets randomly in presentation 1 and 2 3.you will notice that when you move to another sheet in presentation 1 (screen 1) randomoly impress also move to a different sheet in presentation 2 (and viceversa) Actual Results: Impress change the viewd sheet in one monitor when you are navigating in another presentation on another monitor Expected Results: If I am watching sheet 32 on monitor 2, it shouldn't show me sheet 33 only because I want to watch sheet 22 on monitor 1. Reproducible: Always User Profile Reset: No Additional Info: .
Do you use LibreOffice from Arch repo or from LibreOffice official site?
LibreOffice fresh from arch repo. Today also noted some unpleasant interaction between writer (opened on screen 1) and impress (screen 2) on gnome 3.38. It's something minor but I cannot explain myself why touching screen 1 should affect what happends on screen 2 (and viceversa). Tried with and without hardware acceleration (switched on and off).
Sorry I'm on wayland
[Automated Action] NeedInfo-To-Unconfirmed
I couldn't reproduce the issue in a quick test in a Plasma Wayland session with two 1920x1080 screens on Debian testing (libqt5core5a:amd64 5.15.2+dfsg-4, plasma-desktop 4:5.20.5-3). Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 75894d5c6afd3f4d206b50c529d83db9c1f8232d CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Some questions: (In reply to giors_00 from comment #0) > Steps to Reproduce: > 1.open 2 presentations in 2 different screens > 2.navigate through sheets randomly in presentation 1 and 2 1) Do you open them in presentation mode or what exactly are you doing to open and navigate? (I was just opening them in non-presentation mode and navigating between slides in the slide pane, but the other presentation was not affected in my case). 2) Can you possibly create a screencast that shows the behaviour? 3) Can you copy the information from "Help" -> "About LibreOffice"? 4) Does it work if you start LibreOffice from command line like this (i.e. use Qt's X11 platform plugin with XWayland instead of the native Wayland one; make sure to close all LibreOffice processes first): export QT_QPA_PLATFORM=xcb libreoffice --impress (In reply to giors_00 from comment #2) > LibreOffice fresh from arch repo. Today also noted some unpleasant > interaction between writer (opened on screen 1) and impress (screen 2) on > gnome 3.38. 5) So this is in a different setup, using GNOME instead of Plasma? Might be a different issue in this case, can you paste the information from "Help" -> "About LibreOffice" you get in this setup? > It's something minor but I cannot explain myself why touching screen 1 > should affect what happends on screen 2 (and viceversa). You're right, that actually shouldn't be the case and sounds like a bug in either LibreOffice or one of the "lower levels" (like kf5 or Qt, or Gtk, since you are also mentioning GNOME). What is your Qt version?
Created attachment 170198 [details] Screenshot that describe the initial situation This is the situation to reproduce. Now try to click on the left screen and select sheet 2. On the right screen select also sheet 2. Now if yo go back to left monitor and click on sheet 1 you will see that on right screen impress also move to screen 1. I am sorry but I am not able to send a screencast (on wayland it seems impossible). Here you have libreoffice help Version: 7.1.0.3 / LibreOffice Community Build ID: 10(Build:3) CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: kf5 Locale: es-ES (es_ES.UTF-8); UI: es-ES 7.1.0-2 Calc: threaded
Qt version: 5.15.2
(In reply to giors_00 from comment #6) > Created attachment 170198 [details] > Screenshot that describe the initial situation > > This is the situation to reproduce. Now try to click on the left screen and > select sheet 2. On the right screen select also sheet 2. Now if yo go back > to left monitor and click on sheet 1 you will see that on right screen > impress also move to screen 1. Thanks for the clear steps. It still works fine for me when doing this, so I still cannot reproduce. The screenshot shows that you're using the "Tabbed" interface, which may or may not be related. Can you try whether the behaviour is the same with a fresh/temporary user profile? You can e.g. start LibreOffice from command line like this: libreoffice -env:UserInstallation=file://$(mktemp -d) or remove/rename your ~/.config/libreoffice directory temporarily (close LibreOffice first) And this would also be interesting: (In reply to Michael Weghorn from comment #5) > 4) Does it work if you start LibreOffice from command line like this (i.e. > use Qt's X11 platform plugin with XWayland instead of the native Wayland > one; make sure to close all LibreOffice processes first): > > export QT_QPA_PLATFORM=xcb libreoffice --impress >
> > > > You can e.g. start LibreOffice from command line like this: > > libreoffice -env:UserInstallation=file://$(mktemp -d) Still buggy. Changing slide on screen 1 change the slide also on screen 2. > > export QT_QPA_PLATFORM=xcb libreoffice --impress If a copy/paste in a terminal "export QT_QPA_PLATFORM=xcb libreoffice --impress" I got an error (bash: export: `--impress': no es un identificador válido). I omitted "--impress" and nothing happens. Then I started Libreoffice and...still buggy. Same behaviour.
Just would like to add that my workaround is going back to gnome (on wayland)...there, all seems to work fine. So I guess somehow is the mix wayland+plasma that messes all up.
(In reply to giors_00 from comment #10) > > > export QT_QPA_PLATFORM=xcb libreoffice --impress > > If a copy/paste in a terminal "export QT_QPA_PLATFORM=xcb libreoffice > --impress" I got an error (bash: export: `--impress': no es un identificador > válido). I omitted "--impress" and nothing happens. Then I started > Libreoffice and...still buggy. Same behaviour. Sorry, my mistake. You either have to use just QT_QPA_PLATFORM=xcb libreoffice --impress or two separate commands: export QT_QPA_PLATFORM=xcb libreoffice --impress (In reply to giors_00 from comment #11) > Just would like to add that my workaround is going back to gnome (on > wayland)...there, all seems to work fine. So I guess somehow is the mix > wayland+plasma that messes all up. Yes, sounds like this. To further narrow it down: Does SAL_USE_VCLPLUGIN=gtk3 libreoffice --impress work in a Plasma Wayland session and does SAL_USE_VCPLUGIN=kf5 libreoffice --impress work in a GNOME session?
(In reply to Michael Weghorn from comment #13) > QT_QPA_PLATFORM=xcb libreoffice --impress Apparently, it solves the problem (although system became unusable and had to reboot). Please note that I launched 2 instances of impress both from terminal. > Yes, sounds like this. To further narrow it down: Does > > SAL_USE_VCLPLUGIN=gtk3 libreoffice --impress > > work in a Plasma Wayland session Yes it does. It solves the problem and I didn't notice any other negative consequence. >and does > SAL_USE_VCPLUGIN=kf5 libreoffice --impress > > work in a GNOME session? Yes it does. No problem detected. Thank you for your kindness
(In reply to giors_00 from comment #14) > (In reply to Michael Weghorn from comment #13) > > > QT_QPA_PLATFORM=xcb libreoffice --impress > > Apparently, it solves the problem (although system became unusable and had > to reboot). Please note that I launched 2 instances of impress both from > terminal. Launching 2 instances is fine (will use the same process anyway). That this makes the system unusable is weird... (unless you don't have Qt X11 libs or XWayland,... installed, but then it wouldn't work at all). > > > > Yes, sounds like this. To further narrow it down: Does > > > > SAL_USE_VCLPLUGIN=gtk3 libreoffice --impress > > > > work in a Plasma Wayland session > > Yes it does. It solves the problem and I didn't notice any other negative > consequence. > > >and does > > SAL_USE_VCPLUGIN=kf5 libreoffice --impress > > > > work in a GNOME session? > > Yes it does. No problem detected. That's interesting, this would mean that it is actually the combination kf5 on Plasma Wayland (which works OK for me on Debian testing) and kf5 works OK in GNOME. Just to make sure, can you double check that "Help" -> "About LibreOffice" contains "VCL: kf5" for the latter case where it works on GNOME?
(In reply to Michael Weghorn from comment #15) > Just to make sure, can you double check that "Help" -> "About > LibreOffice" contains "VCL: kf5" for the latter case where it works on GNOME? Confirmed: VCL:kf5 on gnome. And it works (no unwanted transitions on the other screen). Version: 7.1.1.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: kf5 Locale: es-ES (es_ES.UTF-8); UI: es-ES 7.1.1-1 Calc: threaded Don't remember if I told you, but I am on arch (vanilla), using an Intel graphic card.
Thanks for double-checking. Maybe somebody else will be able to reproduce...
I don't know if it's something related but I just noticed that on a 2 screen configuration, if you have two different instances of Libreoffice opened (one on screen 1 and one on screen 2) entering in a full screen view mode on screen 1 (CTRL+SHIFT+J) automatically makes libreoffice entering in a full screen mode on screen 2: so it seems to be impossible to have full screen view on monitor 1 and normal view on monitor 2. Just to be clear: Version: 7.1.1.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: es-ES 7.1.1-1 Calc: threaded Gnome 3.38 wayland (arch linux)
With > > SAL_USE_VCLPLUGIN=gtk3 libreoffice --impress > > > > work in a Plasma Wayland session > > Yes it does. and > > SAL_USE_VCPLUGIN=kf5 libreoffice --impress > > > > work in a GNOME session? > > Yes it does. I doubt it can be fixed in any way in LO, because Michael couldn't reproduce. My blind guess would be some problem in kwin or QtWayland or Kf5WaylandClient, but that is just a hunch. I found I can run "weston --xwayland --output-count=2" or "kwin_wayland --xwayland --output-count 2", but both produce broken setups in the Debian buster versions, with either gtk3 or kf5. And I could reproduce this bug once with my Ubuntu focal chroot and running that newer Weston, but still with old buster libraries and LO master build. But in the end LO always crashed left and right (like Gdk-Message: Error 71 (Protocol error) dispatching to Wayland display.) and had a lot of visual problems, so I gave up. And LO even broke some Weston state, so stuff got just "fixed" after restarting Weston. I hope the general Wayland experience is much better, but Debian buster in my setup is definitely not up to it ;-)
Is this still an issue with current LibreOffice and KDE Plasma/kf5 versions?
Dear giors_00, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear giors_00, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp