Why is this a bug?
I find any other behaviour to be horrible.

For instance: start emacs (or any other graphical text editor) from an
xterm. It gains focus. If not, you would actually have to CLICK on it
to begin typing. 99% of all times I open new windows, I do it to
actually WORK in that window. The other 1% I can live with having to
focus the old window.

The current CVS behavior is refined a bit, it has a more complicated
rule copied from Windows XP. 

 a) new normal windows are focused only if the current 
    focus is on the dock or the desktop
 b) new dialog windows are focused if their parent window 
    has focus
 c) clicking on the panel to launch a new normal window focuses
    the panel, which means by rule a) the new normal window 
    will get focus

Doesn't handle running Emacs from an xterm, that's true. Maybe putting
the new Emacs at the front of the Alt+Tab MRU list would make that
pretty tolerable - type Emacs, hit Alt+Tab.

Ok... discussion carried on from 83007. I still think this is the
wrong behaviour.

When you open a new window, I have difficulty understanding that you
do not intend for the most part, to start working in that window right
away.

Dialogs, I understand is just a bug if it doesn't work out, as they
should be getting focus (the bug is that only TRANSIENT dialogs get
focus, and I know where it happens), although I could be wrong about
this being considered a bug.

The whole question, I feel, boils down to the following two usage
patterns:
1. You normally open windows from your current xterm or
nautilus-window, and you want to keep using the current window for a
bit longer.
2. You open windows from your current xterm or nautilus-window, and
you want to start using that window right away.

Personally I'm for 2 all the way. I also happen to think that this is
the way "Joe Average" happens to think. And I don't think that most
people that follows the development of Metacity falls into the "Joe
Average" category. I think this actually requires some usage testing..
perhaps Calum Benson has some ideas?

If Windows XP does the "other thing", this is of course an argument
for going with the idea of not focusing new windows, but I still think
it is the Wrong Way [tm].

Consider the following:
- When you open a new Window from an xterm or Nautilus window, it IS
on top of the stack. How often does it NOT cover up the window that
you indent to use? I tested this under 1024x768.
In Metacity it was 100% of the cases. In Sawfish it was about 80% of
the cases. 
- If the window covers up the xterm or Nautilus window, does it really
make sense to focus the window that is NOT on top of the stack? You
often cannot even see what you are typing in.

The way I see it, if you want to create obvious behaviour and keep the
current window behaviour, you would have to open the new windows
beneath the current in the window stack as well as not focusing it.

As a default I think the window on top of the stack should ALWAYS be
the focused one. Anything else is just crack. (Except for certain
"always on top"-cases of course.

I agree about the stacking, but that's just a bug.

The reason for not always focusing new windows is that sometimes you
didn't launch the new window (it's a popup notifying you of some
unexpected event for example), or you launched it, then started doing
something else. The argument is that sending keystrokes to the wrong 
window is a dangerous or bad thing.

Note that when we have "launch feedback" (meaning of this is attached
to some bug in here) we will be able to special-case launches from the
panel and from Nautilus, without using the odd accident that the panel 
has been focused during the launch process. Maybe that's useful.

Currently things like the panel run dialogue don't start focused
either, maybe that's just a bug.

Maybe we should focus new windows unless they are dialogues?

But honestly, based on (b) we aren't too worried about accidentally
pressing keystrokes in dialogues anyway.

The majority of dialogues pop up in the currently focused window
because they happen in response to an event you triggered. So unless
we *never* focus popups (unless the program tells us that the user
should be expecting this), I think we should just get rid of this
complex behavior and focus new windows.

I know of the problem with for instance accidently hitting enter when
a dialogue pops up, and then not knowing what the dialogue was,
because you didn't have the chance to read it.

This will of course not happen if the new window isn't focused, but
I'm wondering wether perhaps a different way of stopping this is better.

What about the following:
1. Wait 0.5 seconds after the dialog is shown, before you accept
key-presses in it. (Probably annoying and bad though).
2. Use key-presses for the choices that aren't normally used in daily
work. (ctrl-enter, ctrl-esc?).

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

Given the trend of the discussion, I'm resummarizing. Note that I'm
not placing a judgement on what the correct window is :)

I do think the current behavior is a little broken; noticeably wrt the
run dialogue- it suggests, Havoc, that the winXP algorithm isn't
working correctly? or maybe just doesn't handle the menu panel menus
correctly?

Another question to consider: bill, does focus have a11y implications,
or is it presumed that functional alt+tab is 'good enough' for a11y?

The run dialog not getting focus is just a bug in the implementation I
believe.

I'm not liking the winXP behavior all that much honestly, I liked
always-focus better, and we had discussed not focusing the panel on
click anyhow...

Some people insist vehemently that focusing new windows is a security
issue or something though, they might type their password in the wrong
place or accidentally type "rm -rf *" in the wrong window... I'm not
sure I buy that... but AFAIK it's the reason XP has the behavior. Dunno.

WinXP also makes you press CTRL-ALT-DEL to login... Good for
security...pretty bad as far as the human is concerned. I actually
don't know how I feel about such things. Security seems important, but
what is our responsibility of security vs. usability? The most secure
system is the system that's off ;-) On the other hand, clearly
security measures like passwords while affecting usability are
worthwhile. So neither extreme is right.

Hmm, NT made you press Ctrl-Alt-Del to login, but I'm not sure XP
does... at least, the Home edition doesn't cos *cough* I run it on my
laptop *cough*  :)

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

Windows are a mean of communication with the user. If new windows
appear then it's because they expect some feedback and they should get
the focus. I consider that not doing that it's totally broken and it's
just making the user wasting time to get the focus (which usually
involves moving the mouse pointer and clicking somewhere).

Havoc said above that "some people think focusing new windows is a
security issue or something though, they might type their password in
the wrong place or accidentally type "rm -rf *" in the wrong
window..."  I have _exactly_ the same feeling, but when new windows
_don't_ get focus. At least when they do get focus I can see what I'm
typing and react to it [because, as also said above, most of the time
new windows completely cover the place where the focus is] while if
they don't, I have no visual control over what I'm typing.

This kind of stuff [as not focusing new windows, or misplace them (see
#84311)] although is just a tiny little detail when compared with all
the things that a window manager has to do, it's reason enough for me
for making me looking for new window managers because that's what I
feel _every_ single time I have to focus the new window and/or
maximize it.

I know I'm just one more voice in the crowd, and I know that metacity
aims to be minimalist, but unless this is fixed or is controllable by
a setting, or is easily patchable when compiling from sources, then
surely my quest for a window manager that doesn't get in the way won't
stop on metacity, spite the hopes I had on it.

It's better for accessibility if new windows are focussed, arguably. 
Otherwise for instance a blind user won't know the dialog is there
unless their screenreader is configured to interrupt their task to say
"new window created", after which it might take several Alt-TABs to
focus the new window if desired, etc.... complicating screenreader
logic greatly.  It's worse for users of screen magnifiers, without
focus the user won't see the new window at all, unless the magnifier
logic is made more screenreader-like, again a level of complexity that
one would avoid entirely if the policy was just "focus new windows".

If Metacity's focus chain made is easy to "get back to the previous
window" in this case, i.e. Shift-TAB took you back to the
next-from-top window, that would reduce any pain associated with this
policy (not sure if this is the current behavior or not).

As far as security goes, making login/password dialogs modal would fix
this wouldn't it?   

Well, my opinion is more or less that the security issues are bogus, so 
I'm inclined to just focus all new windows again. 

Though there is one fix in CVS people haven't seen yet, which is to
allow dialogs to steal focus from the panel/desktop even if 
they are not set as transients for the currently-focused window.

Yeah, I'm inclined to agree with you Havoc. After using
non-focus-always with Metacity for a while I'm seeing lots of
annoyances where a user would have to grab the mouse when it would
otherwise be necessary. These have a fairly high cost. One option for
security might be to avoid queing input on dialogues until they are
fully painted, or something. It wouldn't remove the issue entirely,
but it might help.

OK, it's done.

Someone write down this bug number so we can dup any other bugs on 
the topic and show the full discussion. Maybe metacity needs 
~/rationales.txt so I don't have to rehash them. ;-)

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

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

I seem to recall that in some of the old Xlib manuals, etc. there are
fairly baroque directions for handling queuing of X events, various
passive key grabs, etc. to avoid the 'security' issues with dialogs,
as well as directions on how to make sure type-ahead always goes where
you want.  These directions assume you're programming your UI in
straight Xlib of course :-/ so I don't know how applicable the
techniques would be.  Perhaps this is something that belongs in gtk+
somewhere, i.e. certain kinds of dialogs could beep instead of
relinquish focus.

I am happy that we're just going back to "always focus" for now.

For future consideration, we could possibly introduce a WM type that
was somewhere in between system-modal and ordinary, so that for modal
dialogs only, we got a beep (or even a frame-flash a-la visual bell)
instead of a focus switch if the user were in a modal dialog when the
new window was created.  This would give a means for things like
password dialogs, etc. to request special treatment regarding focus of
new windows, while still giving a strong user notification.

OK, here is how Win200Pro works ( I guess WinXP is similar ) and I 
like it :

When I am typing , for example in an editor, and a new window tries 
to appear, it does not cover the editor window and steal focus. 
Instead the system nicely lets me finish the sentence in the editor 
and puts a visual ( or audio, I guess this is configurable ) cue that 
a new window is waiting for me. This is useful as I look at the 
keyboard while I type ( like the majority of users , I can't blind-
type ) and I would not notice the new window stealing focus and would 
type the characters into the new window, which may or may not have 
bad consequences. The focus stays with the editor until I change it.

The visual cue that I mentioned is the apperance a new button on the 
taskbar, which is highlighted.

On the other hand , if I start a new program by selecting it in the 
start menu, it will appear and will have the focus.

To conclude, windows tries to adapt to the user , instead of the 
other way around. I wish linux did the same.

If we did this we'd need some standard protocol for "window pending
raise" or something, otherwise it's an accessibility problem for users
who won't necessarily see a visual-only notification.

Yes, if you read the earlier comments on this bug you'll see that 
I originally tried to copy windows XP behavior. 
It was not possible at that time, using unmodified X applications.

However, the new startup notification stuff should let us do a bit
more, as I said on the equivalent bugzilla.redhat.com bug report; 
that's planned at some point. The result will be more like Windows XP.

Anyway, that's already planned. I haven't bothered opening a bug 
tracking the startup notification focus tweaks since I have it 
in my head, but if someone wants to open a new bug for that feel free.

There's no chance though that we'll implement "don't ever focus a new
window." The only planned feature is that when we can use startup 
notification or other hints to make some smart exceptions to the focus
policy then we will. See also recent wm-spec-list@gnome.org discussion.

Bill :

You could use a audio notification or anything else that the user can 
perceive. Besides, users with special needs can set up special 
options ( read: disable focus-stealing-prevention ). Anyone who 
doesn't mind about stealing focus can leave it enabled, others 
disable it. I personally don't mind what the default is as long as 
there is some check box somewhere that allows me to set the behavior 
to something that I like more.

David: we have deaf-blind users too.  My point is that we would need a
consistent notification protocol for something like this in order to
expose the notification programatically - the only way to do the job
accessibly.

We want to avoid having to set things like this to non-default values
for accessibility because that increases the likelihood that users
won't be able to find the setting, and that the feature will be poorly
tested in those scenarios. 

What about the focus-follows-mouse behaviour? Currently if a window opens it
steals the focus and I have to move the mouse to refocus the window I was using.
Could there be a gconf option to completely disable new-windows-get-focus?

See http://bugzilla.gnome.org/show_bug.cgi?id=152004