Bug 161253

I'd also like to note that when the window does not come to front as expected,
it is instead made bold in the window list applet, as if it were newly opened.
This operability is extremely frustrating, however, because it basically
prevents auto-raising without having to select a window in the window list.

Hi Aaron,

This is a feature called "focus stealing prevention".  There are various
problems with allowing windows to pop up on their own any time they want.

Let me give you an example.  Say you are typing a document and a dialog pops up
to inform you of something.  If you are typing at a fast rate then you will be
hitting space bar fairly frequently.  If a dialog pops up quickly and you just
typed space bar, then the space bar will activate the default button and close
the dialog before you have a chance to read it.

Focus stealing prevention detects if you are doing something. If you are then it
 prevents new windows from getting focused.  Instead it makes the glow very
noticeably in the task list of the task bar.  You don't see any glow?

What is the output of 

rpm -q metacity libwnck  

?

$ rpm -q metacity libwnck
metacity-2.10.3-1
libwnck-2.10.0-4.fc4

Okay... I think I understand the idea behind focus stealing, but here are some
issues I have with it:

1. With NEdit, I am manually selecting a window to bring to front from NEdit's
menus. So, whether or not somebody thinks I'm "doing something" I definitely
want the window to come up. However, I've noticed this seems to mainly happen
with an older build of NEdit, not the latest build. I'm still investigating if
there is any difference in the code controlling this.

2. With GAIM, I can choose the option of having it come to front or not on a new
message. I choose the option to have it come to front precisely so it will
interrupt me, and it is a major hassle to have to select the window in the
window list to bring it to front.

I can see many other circumstances where the logic between metacity/libwnck
incorrectly decides not to raise a window. For instance in the case of gaim, it
seems to not raise the window even when I'm not sitting at my desk, but
occassionally (very occassionally) it will raise it when I am actually doing
something. 

Philosophically, I differ with the approach metacity/libwnck seems to take,
because I'd prefer applications themselves to decide how obnoxious they will be
(and hopefully, to let me control it- per application). On the other hand, if
the concern is focus stealing, then I see no reason that a window can't come to
front without stealing keyboard focus, unless it completely obscures the current
window (which is not the case with gaim); but again why not let the application
developers control this?

Regardless, I'd like a way to turn off this "feature". Is there any convenient
way to do this (preferably without hacking code, but if I have to hack, I will)?

Hi Aaron,

I don't know of a convenient way to disable the feature other than downgrading
metacity.

Just out curiosity, do you have a window list (a series of buttons side by side
on the panel) or a window selector menu (an icon in the corner of the panel that
you click on to see a list of applications)?

Ray,

Wow, I never noticed this one as needing info (no email gets sent out when it
changes to needinfo*). 

Yes, I do have a window list, and it does strobe the window buttons as designed.
It's just inconvenient with apps like instant messenger apps in which you're
holding a conversation while doing other things; especially when combined with
metacity's obnoxious click-to-focus default (however I was just inspired to
check gconf and see that they finally re-added that as a gconf setting... joy!
so my concerns are less now because I can click back in my app without it always
raising over my gaim window).

This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

The problem is actually kind of worse now. Gaim windows and the like still do
not come to front, but they do strobe the task bar. However, NEdit windows do
not even strobe the task bar when one attempts to raise an NEdit window from
NEdit's Windows menu. This may be due to NEdit now being built with lesstif
instead of openmotif. Whatever it is, it would be nice if it could at least
strobe the task bar, and even better if the window would actually raise (since
I'm in the same application that requested the window raise).

The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.

Setting status to CANTFIX, however if you still
experience this problem after updating to our latest Fedora
Core release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.

Thank you in advance.

(this message is mass message)