https://bugzilla.redhat.com/show_bug.cgi?id=1061568
Bug ID: 1061568 Summary: Certain X applications do not update window correctly under xmonad Product: Fedora Version: 20 Component: xmonad Severity: urgent Assignee: mathstuf@gmail.com Reporter: dgibson@redhat.com QA Contact: extras-qa@fedoraproject.org CC: haskell-devel@lists.fedoraproject.org, mathstuf@gmail.com, petersen@redhat.com
Description of problem:
When running xmonad with the MATE desktop, numerous applications don't redraw properly - interacting with them has effects behinds the scene, but their window is frozen on the old contents, until switching to another workspace and back forces an update.
Version-Release number of selected component (if applicable):
xmonad-0.11-9.fc20.x86_64 xmonad-mate-0.11-9.fc20.x86_64 mate-session-manager-1.6.1-4.fc20.x86_64 mate-settings-daemon-1.6.2-2.fc20.x86_64 mate-desktop-1.6.2-1.fc20.x86_64 mate-desktop-libs-1.6.2-1.fc20.x86_64
How reproducible:
Every time, for me anyway.
Steps to Reproduce: 1. Log in to xmonad-mate desktop 2. Run any of the following - Network Manager | Edit Connections... - virt-manager - rhythmbox - various others
Actual results:
Application window stays frozen and does not update as you click or type in it.
Expected results:
Application window updates normally
Additional info:
Killing xmonad, then running "marco --replace" results in applications that redraw again. Interestingly, after doing that killing marco and restarting xmonad with "xmonad --replace" leaves the windows redrawing correctly, now under xmonad.
Killing xmonad, then running "xmonad --replace" without running the other WM in between does *not* fix the behaviout though.
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
--- Comment #1 from Jens Petersen petersen@redhat.com --- Hmm I wonder if xmonad-mate needs to run some process to help or if it marco that is helping.
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|mathstuf@gmail.com |petersen@redhat.com Summary|Certain X applications do |Certain X applications do |not update window correctly |not update window correctly |under xmonad |under xmonad-mate
--- Comment #2 from Jens Petersen petersen@redhat.com --- Taking this since I did the xmonad-mate hack. :)
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
--- Comment #3 from David Gibson dgibson@redhat.com --- I wondered about that. I did an strace of the marco process, and couldn't see it spawning off any other helper processes.
Would that strace output, or some other log from the marco run help you?
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
--- Comment #4 from David Gibson dgibson@redhat.com --- Oh, sorry, should have mentioned that temporarily running metacity also fixes things afterwards, so it's not something purely specific to MATE/marco.
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dgibson@redhat.com Flags| |needinfo?(dgibson@redhat.co | |m)
--- Comment #5 from Jens Petersen petersen@redhat.com --- Is this easy to reproduce?
I can edit NM connections no problem and rhythm boxes seems to work fine. This is with the default Fedora xmonad config.
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
David Gibson dgibson@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(dgibson@redhat.co | |m) |
--- Comment #6 from David Gibson dgibson@redhat.com --- Created attachment 860366 --> https://bugzilla.redhat.com/attachment.cgi?id=860366&action=edit xmonad configuration
Well, it reproduces for me every time. But it's not obvious to me what's different between our setups that it's not happening for you.
I've attached my xmonad.hs, in case that provides a clue, although since it works with this config after running marco, I don't see how that would be related.
Let me know any other information which might be helpful
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
--- Comment #7 from Jens Petersen petersen@redhat.com --- (In reply to David Gibson from comment #6)
I've attached my xmonad.hs, in case that provides a clue, although since it works with this config after running marco, I don't see how that would be related.
Can you try moving your xmonad.hs out of the way and restarting xmonad to test the default config?
It might be related to your setting LG3D or your evHook. So testing without those would also be a good idea to pin this problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
David Gibson dgibson@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed| |2014-02-10 02:17:27
--- Comment #8 from David Gibson dgibson@redhat.com --- *facepalm* Yes, the default config works. After some experimentation, I realised the problem was that I had just 'startupHook = setWMName "LG3D"' instead of 'startupHook = startupHook baseconfig <+> setWMName "LG3D"', which makes sense in hindsight.
Thanks for the pointer, sorry for the noise.
Btw, is there a reason that the gnomeConfig doesn't include the fullscreenEventHook from EwmhDesktops by default?
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
Erik Streb del Toro mail@erikstreb.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@erikstreb.de
--- Comment #9 from Erik Streb del Toro mail@erikstreb.de --- Just for other xmonad users searching a solution to this “bug” (misconfiguration):
The solution is to NOT USE the SetWMName extension in order to convince Java that xmonad is "LG3D" (which is a deprecated way of working around the gray java windows). Because this SetWMName breaks GTK3-apps, see the xmonad FAQ: https://wiki.haskell.org/Xmonad/Frequently_asked_questions#Using_SetWMName
Instead use the preferred method (see FAQ https://wiki.haskell.org/Xmonad/Frequently_asked_questions#Preferred_Method) and set an environment variable _JAVA_AWT_WM_NONREPARENTING=1 at startup. I did this by adding the following to my xmonad.hs:
import System.Posix.Env (putEnv)
and adding the putEnv line to the startup of xmonad:
main = do putEnv "_JAVA_AWT_WM_NONREPARENTING=1"
Now I can use all java applications and GTK3-apps.
See: https://code.google.com/p/xmonad/issues/detail?id=559
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |ASSIGNED Version|20 |21 Resolution|NOTABUG |--- Keywords| |Reopened
--- Comment #10 from Jens Petersen petersen@redhat.com --- (In reply to Erik Streb del Toro from comment #9)
Thanks for this! - I almost missed this comment. I will update our xmonad.hs to do this.
(In reply to David Gibson from comment #8)
Btw, is there a reason that the gnomeConfig doesn't include the fullscreenEventHook from EwmhDesktops by default?
I don't know. If you think it is wrong please open an issue upstream or a new Fedora bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version| |xmonad-0.11.1-2.fc24
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
--- Comment #11 from Fedora Update System updates@fedoraproject.org --- xmonad-0.11.1-2.fc23 has been submitted as an update for Fedora 23. https://admin.fedoraproject.org/updates/xmonad-0.11.1-2.fc23
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
--- Comment #12 from Jens Petersen petersen@redhat.com --- Hmm, is an explicit "putEnv "_JAVA_AWT_WM_NONREPARENTING=1" still needed for 0.11.1 (F23) or even F22 (0.11)?
I am not able to reproduce this with 0.11.1 in fedora I think. I tried plain xmonad on F22 too (not xmonad-mate) and itweb-settings.itweb worked okay for me there - but maybe that is not sufficient test??
It's looking to me as if _JAVA_AWT_WM_NONREPARENTING=1 in releases Fedora releases?
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
--- Comment #13 from Jens Petersen petersen@redhat.com --- If it is not needed I would like to revert the change (f23 testing and f24).
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
--- Comment #14 from Jens Petersen petersen@redhat.com --- (In reply to Jens Petersen from comment #12)
It's looking to me as if _JAVA_AWT_WM_NONREPARENTING=1 [is redundant] in [recent] Fedora releases?
Anyone able to test?
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
--- Comment #15 from Fedora End Of Life endoflife@fedoraproject.org --- This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
Fedora End Of Life honza.kurik@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |CLOSED Resolution|--- |WONTFIX Last Closed|2014-02-10 02:17:27 |2015-12-01 22:08:04
https://bugzilla.redhat.com/show_bug.cgi?id=1061568
--- Comment #16 from Fedora End Of Life honza.kurik@gmail.com --- Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug.
Thank you for reporting this bug and we are sorry it could not be fixed.
haskell-devel@lists.stg.fedoraproject.org
-
Red Hat Bugzilla