After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 327530 - gdm loses focus when mouse pointer is outside window (when initially started)
gdm loses focus when mouse pointer is outside window (when initially started)
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
2.13.x
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
: 333658 334729 339383 347733 359387 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-01-18 13:49 UTC by Sebastien Bacher
Modified: 2006-10-17 20:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
center cursor on main head (1011 bytes, patch)
2006-08-03 21:23 UTC, Ray Strode [halfline]
committed Details | Review

Description Sebastien Bacher 2006-01-18 13:49:22 UTC
This bug has been described on https://launchpad.net/distros/ubuntu/+source/gdm/+bug/28712

"My setup is a Xinerama setup, GDM therefore (correctly) displays the login screen on one of my displays.

When GDM first starts up, the mouse pointer is just outside the window. The gdm window doesn't have focus, so I have to nudge the mouse a little bit so the pointer points inside the gdm login screen and focus is automatically given to the username field.

This used to work correctly in Breezy, but is broken in current Dapper."
Comment 1 Trent "Lathiat" Lloyd 2006-02-26 22:16:46 UTC
Confirmed behavior, the pointer sits just to the right, I assume this is the default X position.

Note that you don't need to click on GDM it just needs the mouse over it.
Comment 2 Brian Cameron 2006-03-14 20:27:49 UTC
*** Bug 333658 has been marked as a duplicate of this bug. ***
Comment 3 Sebastien Bacher 2006-03-16 15:02:23 UTC
From the distro bug:

"--- 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."
Comment 4 Brian Cameron 2006-03-17 00:24:56 UTC
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.
Comment 5 Brian Cameron 2006-03-17 02:09:02 UTC
*** Bug 334729 has been marked as a duplicate of this bug. ***
Comment 6 Tollef Fog Heen 2006-03-22 08:41:46 UTC
gdmlogin has the exact same problem; I guess the reason why you don't see bug reports about it is that nobody uses it any more. :-)

As for the unmapped window, yes, it's in gdm_wm_focus_window:

        XGetWindowAttributes (wm_disp, window, &attribs);
        if (attribs.map_state == IsUnmapped) {
                trap_pop ();
                return;
        }

this evaluates to true and the function just short-circuits and returns.

Later, in greeter.c(main) we call gdm_wm_restore_wm_order which causes at least two events to be emitted: ConfigureRequest, then a MapRequest, which then causes the gdmwm to call XMapWindow.

I agree that just setting focus_new_windows to TRUE would be sane.
Comment 7 Brian Cameron 2006-04-28 16:58:24 UTC
*** Bug 339383 has been marked as a duplicate of this bug. ***
Comment 8 Tollef Fog Heen 2006-04-28 17:56:42 UTC
Have you given this any more thought?  I can't see any downsides to just unconditionally focusing new windows, can you? 
Comment 9 Brian Cameron 2006-05-02 05:31:58 UTC
I'm sorry I have been so slow to accept this patch.  I recognize that there is a problem here, but I am not confident this is the right solution.  I especially worry about configurations where people use BackgroundProgram to launch additional applications that have GUI's.  What if the GUI has dialog's, etc. that launch additional windows.  I'd be more comfortable with accepting this patch if someone were able to do a little more testing with it.

Perhaps a less invasive fix would be better, such as fixing the code so it puts the cursor in the right place in Xinerama mode?  Or are there other problems that changing the code to always focus new windows fixes?

I also notice, by the way, that gdmsetup seems to lose focus when it restarts the greeter.  Another annoying problem with the window focus code.
Comment 10 Tollef Fog Heen 2006-05-02 07:10:04 UTC
Note that I'm not actually using Xinerama, I'm using nvidia's TwinView.  (Gdm apparently detects this as something close to Xinerama because it restricts itself to one of my (physical) displays.

I think X is responsible for the initial cursor position since it appears in the middle of one of the (physical) screens if I use Xinerama instead of TwinView.  Having gdm move the mouse pointer about when starting up would be considered bad, IMO.

I could always test with BackgroundProgram and see what the damage would be.

Another option would be to tag the gdmgreeter window with some atom and special-case that in gdmwm to always focus it when it's mapped.  It'd a somewhat-ugly hack, but should work.
Comment 11 Brian Cameron 2006-05-02 16:41:56 UTC
Yes, if you were willing to test and make sure it works with BackgroundProgram, then that would make me much more comfortable with the patch.

Why would it be bad for GDM to move the mouse pointer to the center of its dialog on startup?  This seems reasonable to me.

I'm not sure that always focusing gdmgreeter when mapped would be good.  When gdmsetup is running, it is supposed to have focus instead.  Also, how would users interact with BackgroundProgarms with GUI's if the greeter always had focus?
Comment 12 Tony Houghton 2006-05-02 17:07:30 UTC
What if gdm were to read the pointer's position when it starts and open the greeter on the same monitor instead of monitor 0 or whatever it's doing now?
Comment 13 Brian Cameron 2006-05-02 17:22:34 UTC
Yes, this would be acceptable as well.
Comment 14 Johan Kiviniemi 2006-05-17 14:15:01 UTC
(In reply to comment #12)
> What if gdm were to read the pointer's position when it starts and open the
> greeter on the same monitor instead of monitor 0 or whatever it's doing now?

I am using TwinView (so the mouse is initially positioned to the left corner of the second screen), and i have a TV connected to the second head. The TV's not even turned on all the time. That proposition wouldn't work in my configuration.

It's probably safe to assume the monitor 0 is the primary one.
Comment 15 Brian Cameron 2006-07-17 18:51:05 UTC
*** Bug 347733 has been marked as a duplicate of this bug. ***
Comment 16 Ray Strode [halfline] 2006-08-03 21:23:36 UTC
Created attachment 70166 [details] [review]
center cursor on main head

Does this patch fix the problem? I wrote and committed it to rawhide a couple of weeks ago, but I haven't actually had an opportunity to test it yet.
Comment 17 Brian Cameron 2006-08-08 06:01:13 UTC
Ray, why don't you commit this fix to the 2.15 branch so it can go into the 2.16 release.  I'd like to have this fixed, if possible before then.
Comment 18 Ray Strode [halfline] 2006-08-08 15:09:48 UTC
Sure.  It'd be nice if someone with a multihead setup confirmed that it fixes the problem though...
Comment 19 Brian Cameron 2006-08-08 18:29:13 UTC
Let's leave this open a bit longer to see if we can get verification.  I suspect that including the patch in a release will help get a response to verify it fixes the problem.  Reviewing the code, it looks like it should work to me.
Comment 20 Tollef Fog Heen 2006-08-17 09:50:26 UTC
This patch works around the problem for me, with the cosmetic problem that my mouse pointer is moved from wherever I have positioned it in the time between X having started and gdm starting.
Comment 21 Jason Brower 2006-08-17 17:31:45 UTC
This sounds great.. I would love to see it in edgy eft this october.  Will it be there?
Comment 22 Brian Cameron 2006-08-17 18:36:20 UTC
The cosmetic problem doesn't sound too bad to me.  I think we should go with this solution, at least until someone else comes up with a better patch that fixes the focus problem without needing to move the mouse pointer.
Comment 23 Brian Cameron 2006-10-17 20:16:33 UTC
*** Bug 359387 has been marked as a duplicate of this bug. ***