Created attachment 30143 [details] [review]
let windows steal focus if focus window is a desktop or dock

As for the terminal case, the problem is that you already had a terminal window
open, and launching another merely opens another window of that same instance
instead of launching another instance entirely.  (It's the same problem that
mozilla, epiphany, konqueror, and nautilus suffer from, and was one of the
corner cases Lubos mentioned in his email(s) that he didn't have a solution for.
 He suggested "application startup notification forwarding" as a possible way to
fix the problem.  I also mentioned this a time or two in the way-too-long bug
118372.)  When the launch terminal tells the already running terminal to open
another window, that window is given the USER_TIME that the terminal had, which
is clearly older than the desktop.  If we use Lubos's idea to solve this, then
all apps that contact an already running version of themselves (in order to have
it launch a new window) need to instruct that version to set the user_time to
the appropriate STARTUP time that they would have had.  Perhaps some code to do
this belongs in the startup-notification library, after we agree on the method
on the wm-spec list....

Your fix does seem like a very nice way to mitigate this problem until that can
happen.  This kind of problem will still occur when launching another
gnome-terminal/epiphany/mozilla/nautilus from some other application, be it the
terminal or something else (in particular, the case of clicking on a web link in
an email inside <favorite GUI mail client here> could be particularly common).

I don't understand the problem with the preference dialogs launched by the
panels.  That one has me kind of confused (I wasn't previously aware of that
issue).  /me thinks about it

Could we just use the maximum user_time of all windows in the group?

Ooops, sorry.  I should have said "When the launch terminal tells the already
running terminal to open another window, that window is given the
display_x11->user_time (a global per-application var tracked in gtk+ that equals
that maximum user_time of all windows for the app) that the terminal had, which
is clearly older than the desktop.  

So, no, your suggestion won't work; it's what we already do.  (See
http://bugzilla.gnome.org/attachment.cgi?id=26669&action=view for the
almost-final version of the patch to gtk+ that shows how this works; the part
that handles this is in the gdk/x11/gdkwindow-x11.c file)

I'm not sure if I stated the problem clearly.  Let me restate.  The problem is that:
  a. user uses gnome-terminal A, which remains running
  b. user then has nautilus launch another gnome-terminal (B) via the
     desktop menu
  c. Note that
       gnome-terminal B's TIMESTAMP >= nautilus' USER_TIME
     and
       nautilus' USER_TIME > gnome-terminal A's USER_TIME
  d. gnome-terminal B detects gnome-terminal A running, tells gnome-terminal
     A to open another window, and then exits.
  e. gnome-terminal A opens a new window
  f. metacity doesn't focus gnome-terminal A, because of second half of (c)

If we could get gnome-terminal B to tell gnome-terminal A to set the new
window's _NET_WM_USER_TIME to the TIMESTAMP that gnome-terminal B was launched
with, the problem would be solved.  Of course, we also need to do this kind of
thing for nautilus, epiphany, galeon, mozilla, konqueror, and all other apps
that do this strange
find-out-if-I'm-already-running-and-do-some-weird-magic-to-not-run-again-but-still-pop-up-another-window
stuff.

I tried looking into the panel issues.  For the About GNOME window, the reason
it appears on top is because neither a startup timestamp or user_time is set for
the window, so there's no timestamp to compare.  This results in the old default
behavior being used.

However, for most other applet dialogs I've seen, a user_time is set when the
window appears (a startup timestamp never is, which sounds like a bug to me, but
I really don't understand if these are just dialog windows of the panel or
separate applications).  But the strange thing is that about half of the dialogs
have a newer timestamp than the panel when launched, while the other half don't.
 I can't figure out why that is.

One thing to improve the focus stealing behavior that I thought of was to return
true in the window_takes_focus_on_map function if the currently focused window
is the parent of the window being mapped.  I have a patch that does that (well,
mixed with a bunch of other debugging information), but I don't know of any
testcases to try it out and make sure it works; it won't work for these panel
problems because none of these launched dialogs set a TRANSIENT_FOR hint.

Please don't add the "let focus be stolen from panel/desktop" hack, that is the
kind of hack that hides bugs. No hacks that hide bugs. At least not until much
closer to the release. ;-) Also, it's not really right; if I'm renaming a file
on the desktop or typing into the dict applet I shouldn't get interrupted by
dialogs.

gnome-terminal already forwards a bunch of crap from gnome-terminal A to B,
including some other startup notification stuff, so forwarding the timestamp
should be trivial. Have a look at gnome-terminal/src/terminal.c, specifically in
main() where --startup-id arg gets munged in.

I just installed metacity 2.8.2 as I read in the Changelog that this release
might  address some of the focus problems. But unfortunately nothing seems to
have changed. still if you have one instance of a program already open and you
just create a new one you don't get focus on it. why can't metacity just give
focus to the most currently launched application (no matter if this application
is open in the background or not) as any other window manager does? It's just so
annoying to have to double click on my news reader in the window list after I've
selected an article (in the news reader) which got opened in a new tab of firefox.

Andreas: What do you mean, "still if you have one instance of a program already
open and you just create a new one you don't get focus on it"?  That would never
happen with older releases, because for them Metacity *always* focused newly
launched applications.  However, the behavior you describe sounds like you
didn't update other apps & libraries.  So, some questions:  Did you also update
gtk+ & gnome-desktop & startup-notification & gnome-panel & nautilus & libwnck?
 (Things won't work correctly unless you update ALL of these as well).  If you
did, then this is definitely a bug (which I don't see on my HEAD build), so
please provide the exact versions for each of those that you are using so that I
can try to duplicate and track down the problem. 

Havoc: Should we just start patching all apps manually that do the
forward-launch-request-to-currently-running-version stuff?  It makes me wonder
if we couldn't just provide some kind of library routine somewhere at
freedesktop.org to make this work uniformly for apps like
gnome-terminal/nautilus/mozilla/konqueror...

I have following version of above mentioned components installed:

gtk+-2.4.4
gnome-desktop-2.6.2
startup-notification-0.6
gnome-panel-2.6.2
nautilus-2.6.3
libwnck-2.6.2.1

let me try to explain the above sentence: after gnome startup I open my favorit
news aggregator. inside this program I click on some link. mozilla firebird
comes up and metacity gives focus to it. the window list applet also switches to
the firebird window. now I get back to the aggregator and click a different
link. this link opens up in firefox in a new tab. the firefox window also gets
into the foreground but it is not focused. so the window border of it is grey
and not blue (what would be the case for a focused window with my installed
theme). And in the window list applet the news aggregator seems to be the
application I'm still currently in. 

Ah, yes, epiphany.  That's the
forward-launch-request-to-currently-running-version problem mentioned above. 
We're working on it.  Sorry for the inconvenience.  I added a patch that will
disable the prevention of focus stealing logic in bug 149276 that you can use if
it bothers you too much until we get this fixed.

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

Doh.  s%Ah, yes, epiphany%Ah, yes, firebird/firefox%.  Both apps have the same
problem...  (This is what I get for reading and responding to two bugs at once)

applying your fix to metacity 2.8.2 doesn't change things here.

Okay, that doesn't make any sense, but let's try to dig deeper.  Some questions:

1) You previously stated that after upgrading to 2.8.2 that "nothing seems to
have changed."  Did you really mean that you experienced this bug with some
version of Metacity < 2.8.2?  If so, there's something else screwy about your
setup, you should downgrade to that version of Metacity, file a different bug,
and we should try to find out how that could have possibly happened with that
version of Metacity.

2) The versions you gave for the programs you have installed are all stable
versions, whereas Metacity 2.8.2 is not a stable release.  In particular,
Metacity 2.8.2 depends on the unstable versions of all those programs except
gtk+.  I really think that my patch should have made it work with the stable
versions of those programs, but it's not an option we're going to support.  So
we need to work with all stable versions or all development versions.

3) How did you apply the fix?  (Just making sure you didn't forget something simple)

1. I experienced this with metacity 2.8.1 aswell. I just upgraded today to 2.8.2
as I was hoping this would fix the problem. I can't recall if this problem
already occoured with metacity 2.8.0

3. in metacity-2.8.2/src/ directory I did a patch -p1 < window.patch

just wanted to add that metacity 2.8.0 shows the same faulty behavior

it just come into my mind that we might be talking about two different things.
with your patch applied no newly launched apps will be started in the background
but appears in front of the other already running apps. the new window is also
selected as an active window.
the unselected problem only appears to happen with firefox and newly created
tabs. metacity switches to firefox but the window isn't marked as active and the
window list applet still claims the program I start the link within to be active.

(Not important, but running patch alone isn't enough; you have to also run make,
make install, and then restart Metacity.  But I'm pretty sure from what the rest
of what you said that you really did do that and this isn't this issue...)

What you are describing sounds like a Firefox issue and not a Metacity one to
me.  A little googling shows that firefox seems to default to opening tabs in
the background (http://tinyurl.com/6g94d).  Anyway, if it happens with Metacity
2.8.0 and 2.8.1, it is clearly a different bug than this one, so if you find
some reason that you don't think it's a firefox issue then please file a
separate bug.

I hope that helps,
Elijah

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

yes, I did recompile and install, then stop the old and start the new metacity. 

for me it seems like a metacity issue because other window managers handle it
the way it's supposed to be.

> Havoc: Should we just start patching all apps manually that do the
> forward-launch-request-to-currently-running-version stuff?

Yeah, that's all we can do that I know of.

I would say the only way we can fix this globally is to write a util class like
KUniqueApplication to handle the single-instance apps; we could do this with
D-BUS perhaps, but check recent D-BUS list archives for some notes on the
complexity of it. Or read gnome-terminal source ;-)

Andreas: Yeah, if it doesn't happen with other window managers then it's
probably some sort of Metacity issue.  But this bug is about regressions due to
new code in version 2.8.2 and your problem happened before that new code, so
please file a separate bug.

Back to this bug:
Crispin on IRC made me aware of another manifestation of the forward-user_time
problem that affects more than just the single-instance-app problem:  A user can
click on an email link in a web browser and expect Evolution (or whatever your
favorite mailer is) to open up a compose window.  That window should be focused,
but will require transfering a user_time from the browser to the mail client and
setting the user_time for the new window in the mail client.  So we also need to
patch the various mail clients now (and perhaps gnome_url_show() and any similar
functions).

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

The mail-forwarding issue is really just that the web browser needs to use
startup notification when launching the email reader.  And then we've reduced it
to the user_time-forwarding single-instance app issue.  Perhaps this can be
implemented in the URI handler.

Oh, the web browser launches an email reader?  For some reason, I thought it
might just communicate with an already running one via CORBA or some similar
mechanism which I don't yet understand.  :-)  Cool.  Of course, it does still
add Evo (and other mail readers) to the list of apps that need to be patched...

/me goes back to trying to wrap his head around gnome-terminal code

More from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129380

- Alt+F2 dialog
- clicking tasklist button doesn't minimize it

the others mentioned there I think are fixed (maybe we need to break all these
bugs apart to be sure we don't miss any?)

Uh, no, the others aren't fixed--but they are known.

He mentioned four things in that bug.  I responded there because I want to be
sure to get more info on the minimize thingy.  Anyway, (1) Alt+F2 dialog is like
the other panel dialog problems; we need to file a bug against gnome-panel but I
really would like to understand the problem a little better (see comment 5 in
this bug), (2) startup timestamp forwarding hasn't been implemented for any of
gnome-terminal/evolution/mozilla/epiphany/nautilus/etc. that I know of (and I'm
just a stupid guy so it's pretty slow for me to try to figure it out; plus I
keep on running into other annoying bugs that I want to fix first :-), (3) the
minimizing thingy may be bug 149589 but I need to either duplicate or get more
info or both, (4) is being addressed in the final comments of bug 118372 (and
bug 135024).

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

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

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

I may be really sleepy, but suddenly I share Rob's question: why do new
epiphany/terminal/whatever windows have a timestamp, if the user hasn't
interacted with them yet? Shouldn't the timestamp be per-window, not
per-application?

Is the idea here that if I click a button or menu item to launch a new window,
the new window has the right timestamp? Wouldn't it work in this case to only
set a timestamp if there's a current event (gtk_get_current_event_time())?

Rob's explanation in comment 20 of bug 118372 is the clearest I've read on the
matter: "The idea is that all windows on the display will keep their user time
[i.e _NET_WM_USER_TIME] timestamps updated, and also that new windows will
specify the user interaction timestamp that caused the window to be created."

Here's my extended answer.  First, some points to keep in mind:
  (1) _NET_WM_USER_TIME is per-window, as you expect
  (2) gtk+ has a global per-app variable that assists in setting
      _NET_WM_USER_TIME for new windows, and which works in most cases.
The EWMH version of what Rob said about _NET_WM_USER_TIME: "Clients should keep
the last timestamp from user interaction and set this timestamp in this property
on every new toplevel window before mapping it."

I think the thing that you got confused on was "what should the client (i.e.
app) set their _NET_WM_USER_TIME to for new windows?"  The answer that works
almost all the time, is the timestamp of the last interaction that the user had
with that app.  gtk+ has a variable to track this, and sets the
_NET_WM_USER_TIME timestamp for new windows from that global variable so that
app writers don't have to worry about this.

(As an important aside: apps obviously can't set the _NET_WM_USER_TIME for their
very first window, but that's what the TIMESTAMP from startup notification is for.)

Of course, this method for setting _NET_WM_USER_TIME fails when apps decide to
communicate with previously running instances and request that those instances
open a new window.  In those cases, the apps should obtain the TIMESTAMP from
startup-notification, forward that to the already running instance, and have
that instance set _NET_WM_USER_TIME for the resulting window being opened to the
value of the TIMESTAMP passed.  

(For app writers reading this who are curious, _NET_WM_USER_TIME would be set in
gtk+-2.6 by calling gdk_x11_window_set_user_time.  That API didn't make it in
time for gtk+-2.4, so you'll have to cut-and-paste from the
_gdk_x11_window_set_user_time function in gdk/x11/gdkwindow-x11.c)

Oops, I forgot to add a disclaimer to that last comment.  I was including
details that you obviously would have known simply because I saw you post a
reference to this bug on desktop-devel-list and I wanted my comments to be clear
to anyone from there who read it.  Sorry about that.

I've read the bug report but I don't know enough about these internals to
understand what's happening exactly ...

With 2.8.3 I've these problems:
- alt+F2 doesn't get the focus, panel's issue according to the previous comment.
- if a gnome-terminal is already open and I open a new want it doesn't get the
first plan => hidden by the other windows
- same problem with epiphany

Apparently all these issues are less or more known so I don't know what to do.
Should I fill some bugs against these apps ? Is there a fix or workaround for
the moment ?

A workaround was available in #149276 for metacity 2.8.2 but it doesn't apply
anymore.

Sebastien: Yeah, the issues are known.  Filing a bug for gnome-panel would be
fine (we should have done that...), but filing ones for the other apps probably
won't help much yet.  Lubos said in his email to desktop-devel-list that we'd
first need to change the freedesktop.org startup-notification spec (and, of
course, update the startup-notification code accordingly) before any of the
other apps can be fixed.  (I was going to wait for Lubos to post to the
wm-spec-list because I didn't fully follow his email and I was hoping Rob or
Havoc could take a look.)

Anyway... I posted a new workaround in bug 149276.  It's not the same as the old
workaround (which disabled focus-stealing-prevention entirely).  What it instead
does is just try to disable focus-stealing-prevention in all the special cases
where we've noticed that it currently appears to be failing.  So it's just a
hack, but it should make it look like focus stealing is working correctly in all
cases.

Ok, I'll fill a bug on the panel.

Thanks for the new workaround, it fixes most of the issues. I've noticed a
little problem remaining with it, my gaim list is opened behind my
gnome-terminal when I click on the notify icon. The normal situation is: first
click opens, second click hides ... now I have: first click open in the back,
second click raise on the top, third click hides.

  

Looks like I forgot to mention this previously: when you file a bug on the
panel, please mark it as blocking this bug.

If I understand correctly, you are clicking on an icon outside of gaim (perhaps
a panel applet) in order to open the gaim window list, correct?  If so, you've
just made us aware of another application that has the same kind of issue and
which needs to be fixed.  I wouldn't special-case gaim either, because that
would make it so windows created when receiving IMs steal focus when you're busy
doing something else--which defeats one of the the main purposes of
focus-stealing-prevention.

this is the notification area plugin for gaim I assume.  Which is an affront to
all that is holy, but that's a separate issue.

Yes, I'm clicking on the notification icon of gaim. 

Bug submitted for the panel: 150271

I've an another issue with 2.8.3 + the patch:
* open epiphany
* open gconf-editor
* click one time on gconf-editor in the windows list -> gconf-editor is minimized
* click a second time to open it, it's opened in the background (behind epiphany)

Thanks for filing the gnome-panel bug.

What version of libwnck are you using?

I use the current 2.7 release for all the GNOME modules, libwnck is 2.7.90

Aha, I just looked at the Changelog for libwnck.  There has been no release
since the fix.  You'll need CVS head or wait for a new libwnck release to be made.

I have the same exact problem as Sebastien in Comment #40, but it happens with
every window that isn't maximized.  If i minimize it by clicking the in the
window list, then I give Epiphany (which is maximized) focus, then try to
restore the window I previously minimized, it appears behind the Epiphany
window.  A bit annoying.

James: Which version of libwnck are you using?  That's a known (and fixed) bug
if the version you are using isn't recent enough...

Created attachment 30726 [details] [review]
Hack to make workspace switcher applet's preferences dialog work

This would have taken Havoc far, far less time to figure out.  I spent quite a
bit of time on this bug, and when I finally figured out the problem and a hack
that would fix it, I remembered what Havoc said in comment # 2 of bug 147950.

So, it appears the only difference in why the workspace switcher applet's
prefences window won't be focused and why all the other applet dialogs we tried
(e.g. the about dialog for the workspace switcher or the about or preferences
dialog window for the clock applet) would work is that all the other dialogs
are regenerated each time that the window is wanted (causing gtk+ to set the
_NET_WM_USER_TIME as it faithfully does for new windows beyond the first of an
app) and the workspace switcher preferences dialog is saved and reused.

Anyway, the patch is not meant to be used, but rather just to demonstrate the
problem.  I'll file a gtk+ bug soon so we can get gtk_window_present() fixed.

Metacity is not stealing focus to itself :). Description:

1.- Click the close button of a stopped application (that it is not closed)
2.- Interact with gnome-terminal for example
3.- After some timeout metacity brings up the Kill app dialog, but if gets the focus

Haha, Metacity is guilty of launching an app without using startup notification.
 So the problem here is that in delete_ping_timeout_func of delete.c,
metacity-dialog is launched merely using g_spawn_async_with_pipes.  This means
that when metacity-dialog is run and its window is mapped, there are no
timestamps available for comparison and the window gets the old default behavior
of always-focus.

I'm not sure what the correct fix is, so I'll need Havoc to respond.  But let me
venture a guess:

Get a timestamp passed to the delete_ping_timeout_func of delete.c
(meta_display_ping_window and meta_window_delete are the functions where the
calls to delete_ping_timeout_func are setup and I believe they do have the right
timestamp), and then do some cut-and-paste action from
startup-notification/test/test-launcher.c utilizing the passed timestamp.

I'm a little unsure of this solution because (1) we could use gnome-desktop
(since it has support for launching with startup notification) instead of
cutting-and-pasting from the startup-notification examples, (2) I'm worried that
more apps might have this problem that use the g_spawn_* function and perhaps we
should be doing something more to fix all the apps, and (3) it seems a little
funny to be passing X messages around when they're all going to end up being
received by Metacity anyway; it seems like we could optimize this case (though
I'm not sure whether it would be worth it or not).

I would think you could just add a command line arg to metacity-dialog that's
the timestamp, then in metacity-dialog set the timestamp on the dialog. Pretty
simple, does the job. I don't think using startup notification is right, don't
really want the task list button or hourglass cursor here.

Created attachment 30900 [details] [review]
Make metacity-dialog take a timestamp

Ok, so here's a patch that makes metacity-dialog take a timestamp and set its
_NET_WM_USER_TIME to the timestamp that is passed.  I tested this for the
kill-window dialog and it works great.	I wasn't sure how to trigger the other
two ways that metacity-dialog is called in keybindings.c and session.c, so I
was unable to test them.  I think the portion of the patch for keybindings.c is
right, but I'm worried that the use of meta_display_get_current_time() in
session.c will return 0 for the timestamp and cause the window to not be
focused.  I guess we could have a slowly_obtain_timestamp() function that gets
the current timestamp from the xserver and just uses it in that case.  Any
better ideas?

Comment on attachment 30900 [details] [review]
Make metacity-dialog take a timestamp

For timestamp should use "Time" typedef rather than guint32 (the typedef is to
"unsigned long") - I might sprintf/printf a 
Time using "%lu" and cast it to "unsigned long" just to be sure, see for
example check_use_this_motion_notify. printf formats sort of break typedefs.

No space before paren in strtoul()

Can't include gdk in session.c; I don't think the display current time will be
anything useful anyway. um... the get_slowly() is the best idea I have, I
suppose. Or just unset _NET_USER_TIME on this dialog?

Created attachment 30936 [details] [review]
Updated patch to make metacity-dialog take a timestamp

I did the s/guint32/Time/ in the patch and also did a s/%d/%lu/ in the
corresponding sprintf's.

I added the space for strtoul.

For obtaining the timestamp, I thought of a different solution that I thought
would work better.  This is a dialog that pops up without any kind of user
request and so it seemed to make sense to me to have it never steal focus; thus
I just set the timestamp to 0.

Just a quick clarification on my last paragraph: I was talking about the
lame-app-with-no-session-management-support dialog, not for the
error-on-running-a-keybinding-command or the kill-dialog (both of which should
take focus if the user doesn't do something else while waiting for those dialogs
to appear).

Comment on attachment 30936 [details] [review]
Updated patch to make metacity-dialog take a timestamp

looks good to me, thanks.

Comment on attachment 30936 [details] [review]
Updated patch to make metacity-dialog take a timestamp

committed.

Created attachment 31075 [details] [review]
Patch to disable focus-stealing-prevention

Here's a patch I just applied to cvs to prevent focus-stealing-prevention; hard
code freeze is tomorrow, and there are just too many other modules that would
still need to be patched.

Comment on attachment 31075 [details] [review]
Patch to disable focus-stealing-prevention

not really sure that hard code freeze will really be in effect; it appears
we've slipped a gnome beta release or two.

Well, then perhaps this was misguided; but Havoc okayed it and asked me to make
a release...and I'm already most of the way through making the release.

If it turns out the hard code freeze isn't in effect, we can jump back on fixing
bugs 150910 and 151245 (the two remaining problems) and then undo this, I guess.

Since focus-stealing-prevention has been disabled and we are in hard code
freeze, I'm moving the milestone to 2.10.0.

Ok, since the focus stealing prevention is back to 2.9, I guess we can continue
to list the problems with it here ?

with metacity 2.9.0 and gnome-term 2.9.1
* create a launcher for gt on a panel
* start an instance by clicking on the launcher
* type some stuff in it
* start a second instance with the launcher
=> the second windows get the first plan but the focus is neither in the first
or in the second window (the window's title is bold in the windows list applet).

I get the problem with all the applications in fact epiphany and nautilus too.

First of all, what do you mean by "the second windows get the first _plan_"? 
That's really confusing to me.  However, from your steps to reproduce it's
pretty easy to figure out what you mean.  You are getting bit by the startup
notification forwarding bug that exists in several applications (see bug 151245
for more info).  Those applications need to be patched (you can tell which ones
they are--they're all the ones that contact previously running instances and
tell them to open a new window instead of just having more than one process
running simultaneously).  See bug 156413 for the gnome-terminal patch.  Other
applications need to be patched similarly.  I need to email desktop-devel-list
about this and a few other issues but haven't been able to try out Havoc's
suggestion in a related issue yet (If it weren't for both schoolwork and money
problems that pressed me to spend time trying to find a compatible part-time job...)

sorry for the "first plan", bad english to mean "on the top". 

BTW the gnome-terminal patch is based on non-released features
(sn_launchee_context_get_id_has_timestamp function), it would be nice if
somebody could make a startup-notification release for GNOME 2.9.1.

Yeah, I agree.  Unfortunately, I have zero control over the startup-notification
stuff (I wasn't even able to commit my accepted patch and had to ping a few
times to get it committed...)  Havoc: Can you do that?  If you're too busy, is
there someone else we can ping?

Can you mail sitewranglers freedesktop org and get a cvs account there?

Yeah, I'll give it another try...

Comment on attachment 30143 [details] [review]
let windows steal focus if focus window is a desktop or dock

I'm marking this as obsolete, because the root cause of the problem was bug
150502 (and was further mentioned at
http://mail.gnome.org/archives/desktop-devel-list/2004-August/msg00411.html) 
Anyway, the patch in bug 150502 (which was applied quite a while ago) fixes the
issue.	:-)

Okay, since this is on the 2.10 blocker list (though I don't think it needs to
be anymore), let me summarize where we're at:

Support for this feature is complete in metacity and has been for a long, long
time.  Most all critical libraries (startup-notification, gnome-desktop, gtk+)
and weird apps that need special support (gnome-terminal, epiphany, galeon) have
it or are close.

The biggest problem right now is nautilus' lack of startup-notification support.
 It correctly handles startup-notification as a launcher for the most part (but
see bug 166334, bug 162424, and especially bug 161322), but not as a
launchee--it needs to have "StartupNotify=true" in its .desktop files (bug
163046) and it needs to handle starup-notification information forwarding (bug
166242).

Other than these nautilus problems, there are only enhancements and bugs that
have been discovered/reported recently (which suggests that they are not very
important):

  bug 144897: would be nice to fix but there's a working hack in place
    so it's mostly only code cleanliness now

  bug 151984: a non-essential enhancement designed for users who
    launch things from the command line often

  bug 165939: looks to me like a gedit design bug in that gedit
    explicitly focuses a window that they don't want focused merely to
    get a side-effect that appears questionable to me (and which pbor
    is suggesting they change); however, this bug did point out the
    related gtk bug 166379

  bug 166379: gtk issues with gtk_window_present

  bug 166197: kind of sucks and isn't fixable this release due to API
    additions that would be needed; however Crispin has demonstrated
    that it can be worked around by using both gnome-vfs and gnome-desktop
    together (though he's waiting for a gnome-desktop release before
    committing his changes)

  unreported possible bug: supposedly there may be a gnome_open issue
    though I have seen no bug reports and I haven't verified (a few
    people who ran across other focus bugs thought about gnome_open
    and asked if there might be an issue with it on IRC or in email,
    but I haven't seen or heard anyone claim there is an actual
    problem).

Crispin would make me eat my words about Metacity support being finished... 
adding bug 166395 as blocking this one.

Okay, new update.  Stuff that has been fixed:

Since last time, the major nautilus bugs (bug 163046 and bug 166242) have been
fixed.  There's a patch to workaround the major problems with
gtk_window_present() until gtk+-2.8 when we can deprecate that function and
introduce a new function to replace it that takes a timestamp parameter (though
we really need the gtk+ guys to review the patch and get it in...).  That
gtk_window_present() patch fixes all the gedit issues as well (and may fix some
galeon ones and perhaps others, though the galeon developers wrote their own
equivalent to gtk_window_present() instead of waiting for and depending on a
patch so they probably haven't tested).  Crispin has kicked butt getting Galoen
to work (and has also done lots of Metacity testing including providing
testcases and helped the Epiphany team some).  Christian has committed some
support for Epiphany (see bug 150085, though he doesn't appear to have noted in
that bug that he committed his patches...).  Further, we've had new bugs filed
since that time which have also been fixed--bug 166395, bug 166524, bug 166713,
and bug 167042.

Remaining issues:

So, that means that all that remains is an enhancement (bug 151984), some minor
puntable bugs (bug 144897, bug 162424, and bug 161322), a bug which probably
isn't fixable this release but which can and has been worked around (bug
166197), and a newly reported but fairly annoying bug that I really wish had
been reported much sooner (bug 166722--gnome_url_show needs to take a timestamp
parameter as does the gnome-open executable...it sucks that my normal usage
pattern doesn't ever make use of that function or executable, and others didn't
start flagging it until recently).  Oh, and there's also a new bug that I'm
about to file (metacity needs to use startup-notification for keybinding
commands...)

I'm pulling this off the gnome milestone as I don't think it's a showstopper
anymore; besides luis put bug 166722 on that milestone separately.

Should the remaining patch be commited? Has been accepted-commit_now for a long
time.

Kjartan: It was committed the day it was marked accepted-commit_now (see comment
55); the patch status just wasn't updated...

Another nautilus bug for you at bug 308031 ;)

I'm not that familiar with how much control the window manager has over this,
but there is one focus issue that's causing me grief: Windows which steal the
keyboard do not always steal focus. The effect being that I'm typing into a
window that's below everything on the screen.

Even though the applications stealing the keyboard should set the necessary
hints to handle this, it would still be nice if metacity could detect these and
handle it better. (Denying them access to steal the keyboard would also be a
solution).

Example application is the helper application fedora uses to ask for the root
password.

I apparently didn't add a reference to the mozilla/firefox bug; I'll do that now
so that I can find it quickly to point other people to for new reports (e.g. bug
309787):

  https://bugzilla.mozilla.org/show_bug.cgi?id=223492

What is the status of focus stealing and metacity?  I see all kinds of indication that it should have been fixed in 2.10, but I am running 2.12 and still end up inadvertently hitting enter on pop-up dialogs and typing into other newly-popped-up windows in error.

(In reply to comment #77)
> What is the status of focus stealing and metacity?

The metacity code is great, but apps suck and we can't get everything right unless apps cooperate.  You'll probably need to file bugs against the apps in question; if it's an app that tracks bugs in gnome bugzilla feel free to add me to the cc list.

Oh no!  Are you kidding me?  Applications have to co-operate to not steal focus from other applications?  This seems like a recipe for disaster, no?  All of the applications are never going to be just right.  New apps are going to appear, written by people who won't know anything about this need to co-operate and we are always going to be playing cat and mouse with them.

Is it not as hopeless as it seems somehow?

Evolution (2.4.2.1) seems to be an offender.  Is that possible/probable?  They are not yet co-operating?

(In reply to comment #79)
> Are you kidding me?

Sadly, no.  It gets worse too.  Apps can call XSetInputFocus, for example, to rip focus away from anything at any time they want to and X11 treats it as a demand and gives the WM no opportunity to state whether such requests should be honored or not.  It does happen to notify the WM after the fact that it changed the focus, but that's it (and due to a ton of other issues with grabs and asynchronousness, that notification becomes much less useful than one would like).  It is not technically possible to get focus right without changing X itself or else having full cooperation of apps.  (Note that allowing the WM to deny focus request was a change suggested back in 1990 or so by the people who wrote the ICCCM, but which was never implemented...)

> This seems like a recipe for disaster, no?

If you have a better solution, please feel free to work on it, suggest changes, write a new spec, modify X, or whatever.

> New apps are going to appear, written by people who won't know anything
> about this need to co-operate and we are always going to be playing cat and
> mouse with them.

If they are built on gtk+ or QT, they will at least get most all cases right by default.  Apps that try to contact a previously-running instance and have it open a window instead of running a second instance (e.g. evolution, nautilus, mozilla, gedit, gnome-terminal, yelp; most of which have been fixed but not all) will be the main problem.  KDE has that partially solved with KUniqueApp.  We should write a similar library and get apps to use it instead of having each and every app do it their own way.

> Evolution (2.4.2.1) seems to be an offender.  Is that possible/probable?  
> They are not yet co-operating?

Launching other apps from evolution, or having evolution launched from other applications?  Both are most likely still broken, yes; see bug 273912 for the latter issue.

(In reply to comment #80)
> Sadly, no.  It gets worse too.  Apps can call XSetInputFocus, for example, to
> rip focus away from anything at any time they want to and X11 treats it as a
> demand and gives the WM no opportunity to state whether such requests should be
> honored or not.

Blech.  Indeed though, would a Gnome or GTK+ app itself call that I would start lobbying.  Forunately, hopefully, most Gnome/GTK+ apps stick to the libraries provided.

> If you have a better solution, please feel free to work on it, suggest changes,
> write a new spec, modify X, or whatever.

Sadly, I don't.  I better understand the challenges though.

> Apps that try to contact a previously-running instance and have it
> open a window instead of running a second instance (e.g. evolution, nautilus,
> mozilla, gedit, gnome-terminal, yelp; most of which have been fixed but not
> all) will be the main problem.

Evolution seems to be the biggest pain in my side.  For example, when it's first starting up, it pops up dialogs (passwords, resume old compositions, etc.) and such that steal focus.  Very annoying.  I will file a bug with them then.

> Launching other apps from evolution, or having evolution launched from other
> applications?

As above.  Starting evolution from the Gnome menu, it starts, popping up dialogs, stealing focus when it does.

Thanx for your time and education on this issue.

I may be an oddity here, but I'm not sure I'm really loving the focus stealing behavior.  I've read and appreciate all the arguments for why many people want it, and I think it seems like a good idea for a large number of people.  However, I'm not sure it is the best choice for my particular keyboard-only access style.  For example, if I start apps from a gnome-terminal, gnome-terminal keeps the focus.  Or, if I enable/disable AccessX features from the keyboard, the warning alerts don't get focus.  These various things require me to perform more keystrokes to give focus to the window that I wanted to grab focus in the first place, which I really do not want to do. 

I'm curious if there's an option to tell metacity to go back to the behavior of old?  I've hunted around, but maybe I'm just missing something very obvious.

(In reply to comment #82)

The gnome-terminal thing is a separate issue (bug 326159).  The AccessX warning dialogs not getting focus is merely a bug (in XKB's handling, or lack thereof, of AkbAXN_AXKWarnings; but see bug 303136 for workaround suggestions).

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

Joseph Hill in bug 336780 mentions some good other applications to test -- gksudo programs and the new Ubuntu logout dialog.

Created attachment 86238 [details] [review]
Patch to prevent new windows taking focus

I just can not work with new windows stealing focus so I have to apply this patch.

What about having windows only take focus when no other window is focused?

To have another window take focus the windows that wants the new one taking focus should release focus and the new window if no other window is in focus could take it. (I do not know if it is possible right know to not have any window with focus)


Would it be possible to have an option in metacity to not focus new windows while this bug is resolved?

There may be a workaround, wherein all input is captured within the first second or so (user-configurable time) after a new window opens, particularly if the user has typed something within 1 second before the window opens, and the input is either just swallowed or displayed in a window that says "You just typed the following text, but a new window just opened.  Which window did you intend to type into? (...text...) [Old window] [New window]"

Maybe I don't have the situation straight, but I understand there are two reasons why people might want to avoid new windows gaining focus, one is that they want to keep focus in the old window always, and one is that they don't want to accidentally type something into the new window (including hitting Enter or Space and accidentally choosing the wrong button in a modal dialog).  I think these cases should be handled separately.  The first case can just be a preference ("Never focus new windows"), the second can be handled by typeover-aversion logic something like what I described above.

This should all be fine already, *except for application bugs* or bugs in the app used to launch the app (e.g. gnome-panel) - so the key is to report bugs against apps that don't support startup-notification properly. A dead giveaway is that there's no "busy pointer" when the app is launching, or the "busy pointer" does not go away when the app's first window opens.

Basically if you launch an app, then go back to working in another window, and the new app gets focus, the default action should be to file a bug vs. the app that was focused. It may turn out in some cases that the blame is elsewhere, but most likely it's the app.

The above does not apply if you launch an app from a terminal, in that case there's no real way to fix things. Use Alt+F2 instead and the panel should be able to get it right (I don't know for sure that it does)

I think Elijah had a writeup somewhere to give to app authors on how to fix this issue.

I'm marking this bug as a tracker since I'd prefer to have further discussion of specific features rolled off into new bugs (or other already existing bugs).  But, to respond to the last couple points:

I never made a write-up for "normal" apps, but they should support startup-notification automatically via use of gtk+/qt.  For single-instance apps, the answer is "use Emmanuel's gtk-unique lib (derivative of Vytautus' work last summer) to handle your single-instance-ness".  (and, um, upgrade to gtk+>=2.11)

For the terminal case, it's essentially impossible to get right for everyone; getting shells to launch apps with startup-notification isn't going to happen.  Luckily, those who dislike the default tend to be very knowledgeable unix hackery types who ought to be able to discover the gconf key /apps/metacity/general/focus_new_windows (from bug 326159).  [This is basically the "Never focus new windows" case Luke mentions, or as close to it as I'm willing to support.  Ubuntu has a patch that goes a bit further, I think by adding a third value to this key.]

Luke makes a really good point:
  - When new windows are launched, and we decide to give them focus, users could
    accidentally send keystrokes to them when they intend to send keys to a
    different application.  It may make sense to disable focus (move keyboard
    input to the no_focus_window) for e.g. 0.5 seconds, and then transfer focus
    to the new window after the timeout.
But I think we have this filed in some bug somewhere already?  (and I'm not yet sure if we really want to try that)  If it's not in another bug, it should become a separate bug, though.

Adding the bug report (bug 351092) about porting applications to gtkunique (used to be guniqueapp) in order to fix single-instance app bugs.

Moving things to focus component.  Sorry for spam.

Sorry for commenting on this age-old bug, but I've been trying to follow this issue up since typing (half of) a valuable password into an IRC window this morning, and there is several days (which I don't currently have) of reading to do on the subject.  Before you ask: the IRC client was Empathy, lauched by Ubuntu's indicator applet, and my feelings tell me that that may be the place to complain to.  But my question for the metacity developers is that, if I understood what I have read correctly, Metacity relies on the application and the application starting it to provide correct information about when it was started to prevent focus stealing.  Can Metacity tell whether or not the information provided is "good", or whether it is lacking or incomplete?  If so, it would seem to me to make sense to deny the application the focus if in doubt.  And if not I will leave you in peace again.

In fact, after thinking about this some more in the background, it seems to me that there are only some cases in which it is acceptable for a newly appearing window to steal the focus, and they all have one factor in common: the application having the focus stolen from it *knows that this is about to happen*.  Since you probably aren't too interested in yet more ideas from random users, so I will quite understand if you ignore this, but an application which starts another could easily set a property on its foreground window saying that it expects to have the focus stolen by the new application window that will appear, belonging to a given process ID (and no other, although an application might want to specify that all focus stealing is acceptable).  And if the user starts doing something else in the mean time, the application could withdraw the focus stealing permission.

It might be able to handle this transparently to the application starting the new one as part of the standard Gnome "start new graphical application" procedure.

Actually, even gnome-terminal could handle that mechanism, by setting the process ID of whatever is currently running "in the foreground" inside it.  I'm sure there would be more too it than that of course, but probably not much more.

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.