Under some circumstances, setting "Show windows from all monitors" of Windows Buttons stops working correctly, This can be triggered by other bug[1], which is: if a two-monitor layout is changed using ARandR that was launched from Settings Manager, then the layout is not reloaded after log out/in. (It's not yet clarified as if problem in Xfce or ARandR.) [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1071935 Now if the layout is changed again using ARandR that was launched directly (i.e. from menu, desktop icon or panel icon), the mentioned setting stops working correctly. Steps to Reproduce: 0. Have * two monitors, say A as primary and B as secondary. * ARandR installed, * ARandR launcher on a desktop * the mentioned bug in effect 1. Set up two panels, each bound to one monitor (use "Output" drop-down) 2. On each panel, add "Windows Buttons" 3. In both applets' settings, uncheck "Show windows from all monitors" * now each applet should only list windows currently present on that monitor 4. Open Settings Manager -> ARandR and change monitors' layout 5. Log out and back in * The layout is restored, all works fine 6. Open ARandR using other means, e.g. the desktop icon 7. Change the layout again 8. Open some windows on both panels (better have them have different titles) 9. Observe the panel on monitor B * now the panel lists only windows from monitor A. (At this point windows from B are not listed anywhere) Notes: * As a workaround, the effect can be negated by opening the settings of WB on panel B, and turning the setting in question on and off. Versions: xfce4-panel-4.10.1-3.fc20.x86_64 xfce4-settings-4.10.1-3.fc20.x86_64 arandr-0.1.7.1-3.fc20.noarch
Note that this as already been reported[2] to Fedora tracker, although the circumstances have been clarified a lot since then. [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1068355
This also happens when using a multi-monitor setup that has a panel with window buttons on the secondary monitor. After logging out and logging in, the secondary one will only show windows on the primary monitor, until the settings are openend and the "show windows from all monitors" option is toggled on and off again.
This bug is almost certainly exposed by http://git.xfce.org/xfce/xfce4-panel/commit/?id=0e6c0208130a868f512264375c8e67eddbd5f6c8 Prior to that fix, it was possible to lose windows without rearranging monitors, because windows would only show up on the monitor containing the center pixel of the window, which might be no monitors at all. After the fix, each window is tested against the "current" monitor geometries to find the biggest overlap, then the window shows on that monitor. Note that xfce_tasklist_update_monitor_geometry_idle (gpointer data) is supposed to rebuild the monitor list, so likely this is not a bug in the tasklist, but a problem with the monitor geometry event not firing. I have seen this bug happen, but only when moving monitors with non-standard tools such as gnome-settings-daemon. If I rearrange using nvidia-settings or the xfce tool it does not happen - the monitor geometry is updated correctly.
https://bugzilla.xfce.org/show_bug.cgi?id=10637 is the original bug. If anyone wants to check my code for silly mistakes, this is what it is *supposed* to do: Before the patch, the tasklist would store the geometry of it's own monitor only, and then test the window against that geometry. After the patch, it stores the geometry of all monitors and the *number* of it's own monitor. It tests the window against all monitors to find the one with maximum intersection, then displays the window if the best fitting monitor's number == the monitor where the tasklist is.
Created attachment 5469 Refactor the code again
Here is a patch to test. This implementation of multimonitor tasklist uses gdk_get_monitor_at_window and gdk_get_monitor_at_point directly in the main loop. It does not buffer anything except the number of monitors, and that is only used to disable this code when n_monitors = 1. Therefore this version can only go wrong if Gdk gives false information.
Created attachment 5470 Multimon Tasklist The most conservative version of this patch. Most likely to work. Only stores the number of monitors.
Created attachment 5471 Multimon Tasklist - Alternate Version This version stores the current monitor number which the panel thinks it is on. This version or the patch may still be affected by this bug - if so, we know what is happening.
*** Bug 10159 has been marked as a duplicate of this bug. ***
According to the changelog, xfce4-panel-4.11.0 should have improved multimonitor handling. Does that make a difference?
I did some work on this today and I know what is happening now. The panel can now be configured to stay on a particular output, eg DFP-0. So there are two ways to refer to a monitor: by output, or by number. When you rearrange monitor layout, the monitor numbers can change, but the output names do not. So what happens is the following: 1. You rearrange the monitors. 2. All windows by default stay on the same monitor number. 3. Gdk sends an event to the tasklist notifying the monitors changed. 4. Tasklist queries it's new monitor number, but of course it has not changed. 5. Panel notices that the output numbers have changed, so moves itself (back) to the correct output. 6. Tasklist "my_monitor" is now incorrect, so it shows windows from the wrong monitor. The problem here is a race condition between 4. and 5. The only easy solution here is to just not store the current monitor at all. So the first patch.
I think I can improve on it a little though...
Okay after investigating this more thoroughly I found this problem runs MUCH deeper through the whole panel code. Here's a break-down. First thing to understand is that monitors have two different identifiers. One is the Gdk monitor number, and the other is the Xrandr output name. The relationship between them changes if you rearrange the monitor output: The Xrandr names are fixed to the graphics card outputs, but the gdm monitor numbers depend on the logical layout. So suppose you have two outputs, VGA and DFP. IF your layout puts VGA left of DFP then VGA will be number 0 and DFP will be number 1. If you then rearrange the layout so VGA is on the right, DFP will now be number 0 and VGA will be number 1. When you rearrange the layout, Gdk emits a signal which is caught by both the panel and the tasklist plugin. The tasklist uses the signal to update the visible buttons. It asks Gdk which monitor number it is on, and then displays windows from that monitor. The panel uses the signal to keep itself on a specific output. If you have a panel locked to output VGA, then it will move to Gdk monitor 0 or monitor 1 depending on the current layout. If the tasklist gets the signal first, then it's list of visible buttons will become invalid when the panel moves to a different monitor. Since the tasklist already finished with the signal, there is no way for it to know that the panel subsequently moved. There is another way to trigger this condition: if you change the output for the panel rather than rearranging the layout (ie, in panel settings, change output from "VGA" to "DFP", the tasklist will not update. So how to fix both these problems? The panel has a protocol for signaling updates to the plugins: http://git.xfce.org/xfce/xfce4-panel/tree/panel/panel-window.c#n679 At line 679 is the event that happens when the output changes for the panel. Below is the event that happens when the panel's position changes. Both these events call panel_window_screen_layout_changed (window->screen, window); but the latter also calls panel_window_plugins_update (window, PLUGIN_PROP_SCREEN_POSITION); which sends an event to the plugins. The tasklist plugin catches this event and triggers a refresh. However, there's a problem here: the plugin interface will refuse to send the event if the position (which is the gravity of the panel) has not changed: http://git.xfce.org/xfce/xfce4-panel/tree/libxfce4panel/xfce-panel-plugin.c#n1444 So if we call it from the PROP_OUTPUT_NAME, it will not fix the problem. The plugin will not receive the event. If we fix that problem by dropping the filter from the plugin interface, it *still* won't work, because the events are still sent to the plguin before the panel finishes moving to the new monitor. So there are quite a lot of problems here: 1. The race condition with the Gdk signal. 2. The event filter blocks the Xfce plugin event. 3. The event is fired too early anyway. 4. The event isn't really the right fit for what we're trying to do. It seems to me that the plugins should not be directly listening to the Gdk layout signal. Instead, the panel should trap these and forward them to the plugins *only after it has fully finished processing them itself* - this will fix problem 1. and problem 3. Problem 2 & 4 may be best solved by adding a new event to the plugin API, or by changing the meaning of the existing screen-position-changed event. This will be a fairly large change to the code of both the panel and plugins, but it should also massively simplify the code and clean up a lot of cruft. The attached patch makes everything work in the most lazy, ugly and wrong way possible. It should be considered a demonstration of the problems in the existing code and not a fix.
Created attachment 5492 Ugly workaround.
Alistair, do you plan improving this patch so that it can be pushed to git? It actually doesn't look all that bad to me but I have no way of testing it here (1 monitor). I agree that we should have a new API callback for it but a workaround could be useful too (as long as it doesn't break other things).
I think the patch is as good as it is going to get without an ABI break. I suppose I could add some comments saying it's a workaround for this bug and to be fixed properly later?
Thanks for filing this bug and also the prepared bugfixes in the meanwhile. Just to note that this bug also appears in multi-screen setups in virtual machines using VMware, where currently the started session need to be switched to multi-screen via vmware-user. This is breaking the window buttons item every time, exectly as described... Looking forward to see this bugfix in the next release.
Alistair, it depends whether you believe 4.12 will be more broken with our without the patch :-) For the future, when GTK+3 is here, we can probably afford to extend APIs a bit, since plugins will already need individual porting?
We could apply just the part which switches to using Gdk to determine the best monitor. This should improve things a bit.
Created attachment 5998 Use Gdk to find the best monitor. This is the "good" part of the ugly workaround. Use Gdk to find the best monitor. It doesn't completely solve this bug though. @Andrzejr: This gets rid of the g_new (malloc) stuff you never liked. It's also far fewer lines of code.
It seems like with only "Use Gdk to find the best monitor" then windows will jump back to the correct tasklist as soon as you move them. This is at least an improvement over the previous behaviour where once they were on the wrong monitor they were stuck there until the layout changed again.
Created attachment 5999 Fix task list race condition. You need 5998 from above too. The approach here is not to try to sort out the race condition at all. Make tasklist NOT listen for monitor changes. Instead make it listen for configure-events - ie move/resize events initiated by the panel, or anything else. These events by definition can't happen until after the monitor change has been processed by the panel and the panel has moved itself. This signal might be a bit noisy, but it only does anything when the problematic option is enabled, so it shouldn't hurt anyone not using this option.
The 4.12 release had some multi-screen fixes, but as of 4.12.2 on Gentoo, this bug is still present.
I still have issues with multi-screen layout and disabling [ ] Show windows from all monitor: With multi-screen I usually have a bar for each screen with the "window buttons" applet, showing only items of that screen by disabling that option. After restarting, all applets show only items of one screen. The issue is fixed by toggling the option for every applet by enabling and disabling again. After that the applet is only showing items of that single screen. I guess this is still related to this bug here, if not please put a note. I tested that on 4.12.2 on Gentoo inside a VMware Workstation, but also on a more common setup with OpenSuse Tumbleweed and current xfwm-4.12.2-1.3.
I am experiencing this same issue on my Manjaro installm which should contain a fairly new xfce version. Every time I reboot my machine, the right monitor's panel is showing only the left monitor's window icons. This issue has been open for about 2 1/2 years, are there any plans to fix this soon? Is there already a patch that I could apply to a source version and compile it myself? Is there a proposed fix date?
The same happens to me (dual monitors on desktop on xubuntu 16.04). Normally after switching users (logout/login) and sometimes after the screensaver was active.
Attachment 5998 and attachment 5999 work well for me. Ideally they should be merged.
The patches don't apply anymore in pnale 4.13 / 4.13.1. Could they be rebased?
I was supposed to redo them, but I got busy. They'll need to be reworked for the gtk3 stuff.
I managed to automate the workaround in a shell script (tested on Fedora 26): #!/bin/bash -e # Workaround for https://bugzilla.xfce.org/show_bug.cgi?id=10725 # AKA https://bugzilla.redhat.com/show_bug.cgi?id=1068355 # Author: Sean Flanigan <sflaniga@redhat.com> # This shows which plugins need to have their config fixed: # xfconf-query -c xfce4-panel -lv | grep tasklist # also see: xfconf-query -c xfce4-panel -lv | egrep 'tasklist|include-all-monitors' # and: xfconf-query -c xfce4-panel -l | grep include-all-monitors plugins=$(xfconf-query -c xfce4-panel -lv | grep tasklist | cut -f1 -d' ') for plugin in $plugins; do xfconf-query -c xfce4-panel -p $plugin/include-all-monitors -s true xfconf-query -c xfce4-panel -p $plugin/include-all-monitors -s false done echo Configured these taskbar plugins: $plugins
As of 4.13.3 and more than 4 years later this is not fixed yet and breaking any productive multi monitor workstation. Is there a roadmap when the patches could be integrated?
I also ran over this bug today. Would be very glad about a fix. @Sean Flanigan: Thanks very much for the workaround! I guess this will now be another startup script for me as this bug does not seem to get fixed any time soon.
I also feel this is an annoying bug (running Manjaro) and have to use Seans script every time I switch monitors.
*** Bug 14242 has been marked as a duplicate of this bug. ***
I have pushed updated version of these patches to my user repository: https://git.xfce.org/users/ajb/xfce4-panel/log/?h=mmtasklist
(In reply to Alistair Buxton from comment #35) > I have pushed updated version of these patches to my user repository: > > https://git.xfce.org/users/ajb/xfce4-panel/log/?h=mmtasklist I'm trying these patches. Maybe I'm doing something wrong, but I don't seem to be able to run with three panels properly. The third 'window buttons' item always remains empty, regardless of its settings.
Not sure about that. I have three monitors and two panels on each monitor. One panel from each monitor has a tasklist.
Turns out this was another panel bug, in which new panels don't seem to get a proper height value, causing some plugins to not show items. Seems this patch is working fine!
Alistair Buxton referenced this bugreport in commit 3c2b62db2a795cc83b33c87e48f11e9db0ca2c63 tasklist: Don't listen for monitor changes in the plugin https://git.xfce.org/xfce/xfce4-panel/commit?id=3c2b62db2a795cc83b33c87e48f11e9db0ca2c63
*** Bug 8806 has been marked as a duplicate of this bug. ***