Really?!?  You're getting a window to have focus without it being raised?  How
do you duplicate?  (What focus mode?  What other options do you have set for
metacity?  What position are the windows in?  Where exactly is the mouse?  Are
you moving the mouse and/or clicking while waiting for the application to start?
 What are the exact steps you use to "start" the programs?  If done with the
panel, do you use a launcher or a menu entry?  What's the corresponding .desktop
file?)  I can't duplicate it here (tried with Firefox as I have neither Eclipse
nor "Barry's Emacs" installed).  

For me the second firefox window will not be focused and will not be on top
(which is due to https://bugzilla.mozilla.org/show_bug.cgi?id=223492).  That's
correct behavior given the bug in Firefox/Mozilla.

Agreed my recipe with firefox is as you describe.

Barry's Emacs does not do the startup-notifation stuff that I saw described
as part of other bug reports found via 223492. E.g. pass a time stamp from
launcher app to server app that opens the window.

Can I turn of "focus stealing prevention" in metacity?

Barry

Quick note: I found a bug with z-order problems with windows that have more than
one child; see bug 307875 comment 6 (first paragraph).  That is likely the same
eclipse problem and may be the emacs or firefox issues you mention, but we'd
need more information to tell.

> Agreed my recipe with firefox is as you describe.

I'm not following.  Are you saying that your original claim that the second
firefox window got focus was incorrect?

> [Stuff about Barry's Emacs]

I would need a more detailed explanation of what Barry's emacs is, what are you
actually doing with the window (or windows) as a user, what special messages if
any the application is sending, and what the exact observed behavior is and how
it differs from what you expect.

Here are some point of my confusion: Is Barry's emacs just a fork of emacs? Does
it use motif, gtk+, or something else?  Originally you weren't talking opening a
new Barry's Emacs window (as far as I could tell), but now you're talking about
startup-notification?  Why?  When you said that "when the main window is cycled
to the top of the Z order the window gets focus, the title bar changes etc but
the Z does not change" what did you mean?  In that sentence you claimed it was
cycled to the top of the stack and also claimed that it wasn't.  Which is it? 
Is a new window appearing?  Is the user clicking on an existing window and
expecting it to raise?  Is the app sending some kind of raise-me request (e.g.
XRaiseWindow)?  Does it raise and then get lowered?  Is it just not raised?

> Can I turn of "focus stealing prevention" in metacity?

With a simple patch, but why jump to conclusions?  We have no idea whether your
bug is even related to focus stealing prevention.  If I could get a detailed and
consistent description of what is happening and how to reproduce, we may find
that it's an unrelated issue like the one just found in bug 307875.

re: firefox My claim was incorrect.

Barry's Emacs is older then GNU Emacs and shares no code with it.

Barry's Emacs server uses Motif (not Lesstif). A client program
bemacs is used to send commands to the server that owns the window.
When the bemacs_server receives a command from bemacs it does a
XSetInputFocus call that used to put the window on top and give it
focus. But on FC4 it has focus but is not on top.

Ah, I think I'm starting to understand.  A few more questions about Barry's
Emacs.  What causes the client program to send a command to the bemacs_server
that results in the XSetInputFocus call (e.g does the user click on the window,
does the program decide that it has an important message for the user and thus
attempt to show the window on top and focused, etc.)?  Also, XSetInputFocus has
never resuled in Metacity raising a window to my knowledge, so I'm pretty sure
that something else is also happening--probably an XRaiseWindow call.  Could you
verify?

Typically the bemacs command is issued from a Konsole of gnome-terminal shell
by a human typing it and hitting return.
Also issued in a subprocess from other apps (X11 or console).

I do not issue a XRaiseWindow call - its been commented out in the code for
a very long time. Its been a very long time since I got this code working
and I do not remember the reasons for using XSetInputFocus without a
XRaiseWindow.

XSetIntputFocus causes bemacs_server to get the Focus and be on top under FC3
(Metacity 2.8.6) Infact it works under all the KDE versions I've used and
Mac OS X X11.

Barry

reopening as requested information has been provided.
barry, do you still face this issue? if so, which version are you running?

XSetInputFocus() isn't supposed to raise windows by any means; it merely requests (more like demands) the xserver to switch the keyboard focus to a given window.  The xserver does that without asking the WM for permission (a bug in the design of X).  The xserver then notifies metacity of the change of focus.  metacity handles this in metacity/src/window.c:meta_window_notify_focus().  To the best of my knowledge, that function does not and has not ever raised windows.  Also worth noting is that if an application requests a window to be raise, the xserver does first check with the WM and gives the WM the chance to deny the request.  I'd suspect something like that is happening, but there needs to actually be a raise request somewhere or we haven't done anything wrong.

So, I'd either need to know the functions being called, a simple testcase that I can use, or a verbose debugging log.  Right now, things just don't add up.

(In reply to comment #8)
> XSetInputFocus() isn't supposed to raise windows by any means; it merely
> requests (more like demands) the xserver to switch the keyboard focus to a
> given window.  The xserver does that without asking the WM for permission (a
> bug in the design of X).  The xserver then notifies metacity of the change of
> focus.  metacity handles this in
> metacity/src/window.c:meta_window_notify_focus().  To the best of my knowledge,
> that function does not and has not ever raised windows.  Also worth noting is
> that if an application requests a window to be raise, the xserver does first
> check with the WM and gives the WM the chance to deny the request.  I'd suspect
> something like that is happening, but there needs to actually be a raise
> request somewhere or we haven't done anything wrong.
> 
> So, I'd either need to know the functions being called, a simple testcase that
> I can use, or a verbose debugging log.  Right now, things just don't add up.
> 

Let me turn this on its head. Rather then find out what changed
from FC3 to FC4 just tell what I need to code.

How do I code a Motif/X11 app to put itself into the foreground?

I was calling XSetInputFocus only. This gives bemacs input focus
and its tab in the Window List flashes.

Adding a call to XRaiseWindow does not change the behaviour.

I assume that metacity noticed something about bemacs and started
the flashing of the tab. Is that something an attempt to get into
the foreground?

Barry

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

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