Bug 371545

Comment 1 Markus Keller 2012-08-20 10:10:37 EDT

Created attachment 220048 [details]
Snippet

I also get this message from the window manager when I
- start a bare X session
- run the metacity window manager from a terminal
- run the attached snippet
- give focus to another window (e.g. the terminal)
- wait 2 seconds

=> message is printed to terminal, but the shell.forceActive() correctly activates the shell

Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1800028 (Snippet Sh)
Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.

Comment 2 Markus Keller 2012-08-20 10:11:54 EDT

*** Bug 341757 has been marked as a duplicate of this bug. ***

Comment 3 Markus Keller 2012-08-23 09:52:42 EDT

I don't get the _NET_ACTIVE_WINDOW message on normal operations with Eclipse SDK 4.3.0 I20120814-0800 (e.g. on Help > About Eclipse).

But I do get it with the attached snippet. However, you could argue that the message is in fact OK in that case, since the snippet is really a bit rogue in that it steals the focus out of nowhere (i.e. not as a direct reaction to a user event). That's also a scenario that often occurs in JUnit tests.

I don't think SWT has to do anything about these messages.

Comment 4 Dirk Lehmann 2012-09-18 03:24:10 EDT

Same problem here on Fedora 17 x86_64 (Gnome Shell 3.4.1) using Indigo SR2 and Juno.

Can be reproduced by:
Debug Application->Run into breakpoint 
-> No input is taken from mouse or keyboard. Need to kill eclipse via second tty.

~/.xsession-errors:
Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x2800ab8 (Java - obs)
meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.

Comment 5 Markus Keller 2012-09-18 08:08:03 EDT

(In reply to comment #4)
> Same problem here

Nope, that sounds like a different problem. This bug is just about the _NET_ACTIVE_WINDOW message, and not about a UI freeze.

If you can reproduce a freeze and it's not because the breakpoint is in a UI callback method (bug 20006), then please file a new bug for JDT / Debug and give more concrete steps to reproduce.

Comment 6 Dirk Lehmann 2012-09-18 10:34:07 EDT

(In reply to comment #5)
> (In reply to comment #4)
> > Same problem here
> 
> Nope, that sounds like a different problem. This bug is just about the
> _NET_ACTIVE_WINDOW message, and not about a UI freeze.
> 
> If you can reproduce a freeze and it's not because the breakpoint is in a UI
> callback method (bug 20006), then please file a new bug for JDT / Debug and
> give more concrete steps to reproduce.


Thanks Markus. You're right my problem is bug 20006. (and thus workaround (putting -Dsun.awt.disablegrab=true in debugged application) works fine for me)

Comment 7 Patrik Dufresne 2016-01-31 10:33:12 EST

Sorry to bring back this issue.

I'm running Mars.1 Release (4.5.1) Build id: 20150924-1200. On Debian Jessie x86_64 with Java 1.7.0_95. and I'm experiencing the same issue.

While using Eclispe, I see alot of message in syslog similar to the following:
Jan 31 10:22:03 ikus060-t530 gnome-session[2899]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x342cb82 (PyDev: Glo)
Jan 31 10:22:06 ikus060-t530 gnome-session[2899]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3400791 (Minarca - )
Jan 31 10:24:01 ikus060-t530 gnome-session[2899]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3400791 (Minarca - )
Jan 31 10:24:02 ikus060-t530 gnome-session[2899]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3435d70 (Choose imp)
Jan 31 10:24:04 ikus060-t530 gnome-session[2899]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3400791 (Minarca - )

Comment 8 Jan Haensli 2016-08-31 12:30:51 EDT

Shell#bringToTop(boolean force) line 596 is responsible for this error message. 

All windowManager except "metacity" gdk_window_focus is called with OS.GDK_CURRENT_TIME, which seems to be always 0. (static final int).


void bringToTop (boolean force) {
...
...
	} else {
		/*
		* Bug in metacity.  Calling gdk_window_focus() with a timestamp more
		* recent than the last user interaction time can cause windows not
		* to come forward in versions > 2.10.0.  The fix is to use the last
		* user event time.
		*/
		if (display.windowManager.toLowerCase ().equals ("metacity")) {
			OS.gdk_window_focus (window, display.lastUserEventTime);
		} else {
			OS.gdk_window_focus (window, OS.GDK_CURRENT_TIME);
		}
	}

Either OS.GDK_CURRENT_TIME should never be 0 or in case the windowManager is "mutter" (Gnome 3) we should call "OS.gdk_window_focus (window, display.lastUserEventTime);" as well.

Comment 9 Brian de Alwis 2017-03-09 23:25:23 EST

I like this behaviour as it help diagnose odd test failures under Xvnc when a dialog unexpectedly pop up!

Comment 10 Jan Haensli 2017-03-10 07:45:51 EST

(In reply to Brian de Alwis from comment #9)
> I like this behaviour as it help diagnose odd test failures under Xvnc when
> a dialog unexpectedly pop up!

I think we should avoid to fill eclipse-ide users' .xsession-errors with warnings  just to help to diagnose odd test failures in special debug situations.

Everytime I open the "Open Type" dialog, I get one of these warning lines:
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x481f0da (Open Type )

Then when closing the "Open Type" dialog I get an additional
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x4800460 (Neon ...)

Comment 11 Eric Williams 2019-11-01 15:17:23 EDT

The solution here is to fill the time field of gdk_window_focus(). GTK says it's safe to use GDK_CURRENT_TIME (which is 0, by the way), but that doesn't stop the error messages. I'll prepare a patch to address this.

Comment 12 Eclipse Genie 2019-11-01 15:18:56 EDT

New Gerrit change created: https://git.eclipse.org/r/151890

Comment 13 Eclipse Genie 2019-11-01 15:44:07 EDT

Gerrit change https://git.eclipse.org/r/151890 was merged to [master].
Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=bb4b85528d973e7f97e2a0b0f632b4f0f8401b9a

Comment 14 Eric Williams 2019-11-01 15:47:43 EDT

(In reply to Eclipse Genie from comment #13)
> Gerrit change https://git.eclipse.org/r/151890 was merged to [master].
> Commit:
> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/
> ?id=bb4b85528d973e7f97e2a0b0f632b4f0f8401b9a

In master now. User activated (with the mouse or keyboard) dialogs shouldn't generate this error anymore. Shells opened programmatically might still do it -- there isn't much we can do about that unfortunately. But this should fix most of the use cases.

Sorry it took me so long to fix this one.

Comment 15 Eric Williams 2019-11-19 08:55:56 EST

Verified in I20191119-0510.