Description of problem: When using the Window menu to navigate between open files in LibreOffice, if using the GTK3 VCL, there are considerable lags between what that list presents and the actual current state of open files in the application. (I find navigating using the Window menu faster than any other means in Gnome 3, and so I hit this UI rough edge on a daily basis, e.g. I was just trying to move back and forth between three spreadsheets many times in the course of a particular task and kept tripping over this, as I have decades of ingrained habits and expectations as concerns this UI behaviour.) This occurs only under GTK3. When the VCL environment is GTK2 or KDE, there is no such problem. The underlying issue presents two related problems in the UI: files that have been closed are listed as still open, and the presently selected file indicator (bullet) sometimes shows against the wrong file. Version-Release number of selected component (if applicable): 5.0.5.2-2.fc23 How reproducible: Always. Steps to Reproduce: 1. Open a file. 2. Open a second file. 3. Click on "Window". Note the second file is correctly shown as having focus, via the bullet indicator. 4. Use this list to navigate back to the first file you opened. 5. Click on "Window" again. Note the wrong file is shown as having focus (the file you just left). It doesn't matter how long you wait to do this. If you wait a minute before clicking, it's still wrong. It takes a second click on the menu system to force the list to actually update correctly. 6. Close the second file you opened. 7. Click on "Window" again. Note that the file you just closed is still listed, and is shown as having focus. 8. Click on "Window" a second time. Note the list has now been refreshed and is correct. (The behaviour is actually inconsistent in this regard. Sometimes one can open a second file, click on "Window" and it's not listed. Also, one can create a new file, save it, close it, and then its pre-saved name [e.g. "Untitled 1"] suddenly appears in the list. The list apparently can revert to show prior/stale versions of file names as well.) Actual results: (As above.) Confusion for those of us who navigate quickly by assuming the bullet indicator on a list represents the file that actually has focus and that the list of open files is accurate. Expected results: The files listed in the "Window" menu should be consistently representative of the current application state.
and under wayland using the menu doesn't seem to bring the new window to the foreground. it gets focus but is not brought to the front. All part of the same thing I guess
My problem seems to be wayland only and I've logged it with a test case against gtk. I can't reproduce your problem at all. You are using stock GNOME3 right ? Or some different window manager or any not-default settings that might be different to my default out-of-the-box setup ?
I've probably miscommunicated something, sorry. I'm using stock Gnome 3, without any changes in Tweak Tool other than for font rendering. However, I don't have the libreoffice-gtk3 package installed. (That's because it says "This plugin is experimental and it is not suggested for normal use.") So my environment may not be using the GTK3 VCL at all (so my summary was wrong), but from my perspective LibreOffice is integrated into the GTK3 look and feel, and this behaviour only occurs under Gnome 3. (So perhaps it's that I don't have libreoffice-gtk3 installed that's actually the problem? Presently it isn't included by default in a fresh installation, as I just put stock Fedora 23 Workstation on another machine a couple of weeks ago and I see the problem on it.)
(Of course, all pure GTK2 applications automatically get the GTK3 look treatment in Gnome 3. Having researched this a bit it seems I must be using the GTK VCL not GTK3.)
aha, indeed now I can reproduce this
The problem started with https://cgit.freedesktop.org/libreoffice/core/commit/?id=eda624641b34a7d4315388c8ec1aebe44f63982e and was fixed by the referenced 97665 Document Foundation issue (by accident I feel)
I grabbed the libreoffice-5.0.5.2-4 build from Koji and tested it, and it seems to be fixed. (Certainly it passes the test steps I provided originally.)
libreoffice-5.0.5.2-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9d3c3f1921
libreoffice-5.0.5.2-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9d3c3f1921
libreoffice-5.0.5.2-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.