gdm loses focus when mouse pointer is outside window (when initially started)

Thanks for your bug. I've forwarded the issue upstream: http://bugzilla.gnome.org/show_bug.cgi?id=327530

This looks like a duplicate of #5951.

* Marius Gedminas

| Public bug report changed:
| https://launchpad.net/malone/bugs/28712
|
| Comment:
| This looks like a duplicate of #5951.

Indeed.

--- gdm-2.13.0.9/gui/greeter/greeter.c 2006-02-17 02:08:55.000000000 +0100
+++ gdm-2.13.0.9.xinerama/gui/greeter/greeter.c 2006-03-14 13:15:40.000000000 +0100
@@ -1344,7 +1347,7 @@
       /* Run the focus, note that this will work no matter what
        * since gdm_wm_init will set the display to the gdk one
        * if it fails */
- gdm_wm_focus_window (GDK_WINDOW_XWINDOW (window->window));
+ gdm_wm_focus_new_windows (TRUE);
     }

   if G_UNLIKELY (session_dir_whacked_out)

is a patch which fixes this problem for me and doesn't appear to have
other effects.

The reason why gdm_wm_focus_window can't be used is the window is not
mapped yet, so trying to focus it will fail. I'm unsure why it's not
mapped, though.

--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
                                                                      `. `'
                                                                        `-

Upstream comment:

"The problem with using gdm_wm_focus_new_windows is that this turns on the
focus_new_windows flag and this never gets turned off. You'll notice this is
normally only used when a pop-up is going to be displayed. Actually this seems
sort of broken to me. Do we want gdmlogin and gdmgreeter to always just make
focus go to the last window displayed? If so we could perhaps rip out all the
gdm_wm_focus_window calls and just put a single gdm_wm_focus_new_window (TRUE)
call in there.

But, this does seem strange. If you have a bit of time, I would appreciate if
you could look into this a bit furter so we could understand what is going on
here. Since these calls are after the gtk_widget_show_all and
gtk_widget_show_now calls, I'd expect that the window would be mapped. Also, I
notice that gui/gdmlogin.c has pretty much the same gdm_wm calls, but people
only seem to complain about this problem with gdmgreeter. Do you notice the
same problem in gdmlogin? I'm assuming you can also debug the gdmwm code and
see if the window is also unmapped there when the gdm_wm_focus_window call is
made? If we see the problem in both programs, then I'd be happier fixing the
code as you suggest in your patch.

When you say the window is unmapped do you mean it isn't drawn to the screen or
the gdmwm code doesn't seem to know about the window yet? Note that
gdm_wm_init calls add_all_current_windows() and this should notice the window,
and add it to the list. If this is failing, then perhaps there is a race
condition where the window's MapNotify event is happening after the call to
gdm_wm_focus_window. You could probably test this by putting a breakpoint in
the event_process function and see if the code has already passed the
gdm_wm_focus_window function by this time. If this is the problem, I'd lean
towards just setting focus_new_windows to TRUE all the time, because I'm not
sure how we could better manage the race condition. It would seem weird to
make gdmgreeter wait for the MapWindow call before callng gdm_wm_focus_window."

Is this goign to get fixed for dapper?

Trent: if it's fixed you will know, waiting for upstream comments at the moment as you can notice if you browse the GNOME bug pointed

Changing to confirmed.

fixed upstream

This is fantastic news! Thanks for your attention on this.

Marking upstream task as "Fix Released" ...

should be fixed to edgy, marking as fixed, feel free to reopen if that's not the case

Just to confirm, this works fine for me in edgy

This work for me in Edgy now as well. Thanks.

Ohoh... perhaps it work on Edgy, but in Jaunty the bug is present !

It the mouse pointer is just outside the window when GDM start, the gdm window doesn't have focus.