Description: If a same user of a given host has a libreoffice window opened via ssh, and then tries to open another windows locally, then the new window does not open locally but on the distant display. Steps to Reproduce: 1. From host2, login via ssh into host1 : ssh -X user@host1 2. Launch a libreoffice window : lowriter (or localc, or...) 3. Get off your seat, change room, go to host1. 4. Working locally on host1 as the same user, try to launch a libreoffice window : lowriter (or localc, or...) Actual Results: No window opens in host1. However, if you change seat again and go to host2, your new window is there... Expected Results: The new window should open locally Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 5.1.6.2 Build ID: 1:5.1.6~rc2-0ubuntu1~xenial10 CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; Locale: fr-FR (en_US.UTF-8); Calc: group
Thank you for reporting the bug. It seems like you're using an old version of LibreOffice. Could you attempt to reproduce this bug using a newer version of LibreOffice and add some additional information to this report about the results with the newer version?
host1 has been upgraded to Ubuntu 20.04 LTS Therefore libreoffice on host 1 is now the following : Version: 6.4.3.2 Build ID: 1:6.4.3-0ubuntu0.20.04.1 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: fr-FR (en_US.UTF-8); UI-Language: en-US The behaviour has not changed.
Rule of thumb is search before reporting and confirming. Looks like a duplicate, I mark so. If you disagree, write details and reasons and set Unconfirmed. *** This bug has been marked as a duplicate of bug 120903 ***
I may not understand anything but it doesn't look like the same bug for me : in my case I have problem with different X displays, one being tunneled via SSH, and the main window is opening on the wrong display. In the case of Bug 120903, the question is about -dialog- windows opening in another -screen- (not display) as the main window. It may be the same bug having these two consequences, but until it is found and corrected that does not seem obvious at all to me...
Hello Fabien, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear fabien.perdu, 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
I reproduced this with LO 7.2. It's not about the version. Based on explanation in bug 141960, I mark this NotABug. If you disagree feel free to explain why this case would be different. Missing here in the report was use case, what for Expected behavior would be used.
gedit works the same.