Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1061568 - Certain X applications do not update window correctly under xmonad-mate
Summary: Certain X applications do not update window correctly under xmonad-mate
Alias: None
Product: Fedora
Classification: Fedora
Component: xmonad
Version: 21
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-02-05 05:57 UTC by David Gibson
Modified: 2015-12-02 16:08 UTC (History)
5 users (show)

Fixed In Version: xmonad-0.11.1-2.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-12-02 03:08:04 UTC
Type: Bug

Attachments (Terms of Use)
xmonad configuration (1.96 KB, text/x-haskell)
2014-02-07 02:14 UTC, David Gibson
no flags Details

Description David Gibson 2014-02-05 05:57:55 UTC
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):


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.

Comment 1 Jens Petersen 2014-02-05 08:41:48 UTC
Hmm I wonder if xmonad-mate needs to run some process to help
or if it marco that is helping.

Comment 2 Jens Petersen 2014-02-05 08:42:59 UTC
Taking this since I did the xmonad-mate hack. :)

Comment 3 David Gibson 2014-02-05 23:10:43 UTC
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?

Comment 4 David Gibson 2014-02-05 23:11:54 UTC
Oh, sorry, should have mentioned that temporarily running metacity also fixes things afterwards, so it's not something purely specific to MATE/marco.

Comment 5 Jens Petersen 2014-02-07 01:38:27 UTC
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.

Comment 6 David Gibson 2014-02-07 02:14:45 UTC
Created attachment 860366 [details]
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

Comment 7 Jens Petersen 2014-02-07 06:59:55 UTC
(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.

Comment 8 David Gibson 2014-02-10 07:17:27 UTC
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?

Comment 9 Erik del Toro Streb 2015-07-31 10:47:10 UTC
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:

Instead use the preferred method (see FAQ 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.


Comment 10 Jens Petersen 2015-08-05 04:00:11 UTC
(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.

Comment 11 Fedora Update System 2015-08-05 06:11:25 UTC
xmonad-0.11.1-2.fc23 has been submitted as an update for Fedora 23.

Comment 12 Jens Petersen 2015-08-27 11:04:31 UTC
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?

Comment 13 Jens Petersen 2015-08-28 05:53:47 UTC
If it is not needed I would like to revert the change (f23 testing and f24).

Comment 14 Jens Petersen 2015-08-28 06:15:20 UTC
(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?

Comment 15 Fedora End Of Life 2015-11-04 15:55:54 UTC
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.

Comment 16 Fedora End Of Life 2015-12-02 03:08:07 UTC
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

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.