XMPP login box is a focus thief

[ArunRaghavan]

I have a couple of Yahoo accounts a few XMPP accounts. When I start Pidgin, the Yahoo account login boxes pop up immediately, and I start typing the passwords. A couple of seconds later, the XMPP sign-in boxes pop up and steal focus, interrupting password entry.

Ideally, the first login window to pop up should grab focus and the rest should wait patiently to get focus once I'm done with the first password entry.

[deryni]

I just spent a minute or two looking into this and as far as I could tell we only create and show the window, we don't tell it to take focus or even tell the window manager to present it. What de/wm are you using? Gnome? Windows?

[ArunRaghavan]

Replying to deryni:

I'm using Gnome, with Metacity 2.16.8

[deryni]

Do you have focus stealing prevention turned on or off? If you have it on do you have any overrides set (does Gnome even let you do that)? Sean, you use(d) Gnome, comments?

[seanegan]

It looks like you have to jump through hoops to get Metacity not to give your new windows focus. However, I'd say this is a problem more with how we input passwords than a window manager issue. We should have just one "enter your passwords" window, rather than 13 dialogs all over the place.

I'd target this for 2.2.0, since it would require new API, but we don't have a 2.2.0 milestone yet. I'm assigning this to Richard, because for some reason I think he expressed interest in this problem at some point.

[deryni]

We could use something like the old 'connecting' window! =)

[trac-robot]

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

[ArunRaghavan]

It seems ridiculous that the bug is closed after 14 days of inactivity.

[deryni]

That's the way the 'pending' status works, if we request comments from the poster and they fail to respond the bug gets closed after two weeks because the chances of the poster coming back are slim-to-none. I will re-open the bug (as Sean stated he intends to work on this or at least deputized Richard to work on it =) but notice that I asked a question of you and you failed to answer it, which is why the pending kicked in. I am still certain that the problem here is not ours but rather your window manager/desktop environments insisting to focus newly created windows and that a less damaged environment would allow you to have the password windows *not* be given focus.

[ArunRaghavan]

Replying to deryni:

That's the way the 'pending' status works, if we request comments from the poster and they fail to respond the bug gets closed after two weeks because the chances of the poster coming back are slim-to-none. I will re-open the bug (as Sean stated he intends to work on this or at least deputized Richard to work on it =) but notice that I asked a question of you and you failed to answer it, which is why the pending kicked in. I am still certain that the problem here is not

deryni: Thanks for reopening this. I do understand that it is painful to have a lot of open bugs lying around with no resolution in sight. The reason I thought it was unreasonable to close the ticket is that I really have no way of being notified when something changes. Is there some way to enable these? If not, should I file a bug requesting that TracNotification be enabled?

ours but rather your window manager/desktop environments insisting to focus newly created windows and that a less damaged environment would allow you to have the password windows *not* be given focus.

I agree that the Metacity behaviour is not nearly ideal. I wasn't able to find any way to tackle the focus problem by tweaking settings (but I didn't really try fooling around with gconf settings etc.). Considering that Gnome+Metacity is not really a minority DE, changing the DE isn't really a feasible solution to the problem.

BTW, what WM would you recommend which tackles this problem elegantly (and how _does_ it tackle this)?

[deryni]

You should be getting emails from trac whenever a ticket you are involved in changes, are you not getting those? Did you set up your email address with your account correctly?

I use ion3 which is decidedly not a mainstream window manager, but it solves this problem by allowing me to control where windows show up so I can have the password windows always show up in a known location and therefore not pop up in front of me and take my focus. A number of window managers allow for similar configuration, though it is a shamefully small number. Gnome/Metacity is not known for allowing for much configurability (by design) and as such I imagine getting it to do something reasonable will be difficult if not impossible. KDE has historically been somewhat better about allowing for control and should allow you to tweak the focus stealing prevention stuff to hopefully get this to work (Gnome's implementation of focus stealing prevention might help as well, though has always tended to be less friendly than the KDE implementation). I don't really recommend using either of Gnome or KDE for people who really want functional window managers because they tend not to be environments that make that easy to do.

Sorry it took so long to respond to this. Fixing how we accept passwords would certainly minimize the damage here and should be done, but isn't a real fix either.

[ArunRaghavan]

Replying to deryni:

You should be getting emails from trac whenever a ticket you are involved in changes, are you not getting those? Did you set up your email address with your account correctly?

I suck. :( There was a typo in the email address. Sorry about the trouble.

[nix_nix]

Doesn't Pidgin have a feature whereby new conversation windows "pop under" and then set the URGENT hint? The password dialogs could pop likewise. There /is/ a caveat, however: If they pop under, they pop under /everything/. Ideally, the first password dialog should come on top, and the rest should pop under it, but no other windows. That's a tall order.

Of course, a nice, albeit risky maneuver would be to accumulate all the pidgin_request_field groups required by all the accounts, and present them in one giant pidgin_request_fields() dialog. Then the user could simply tab down through the list, typing in each password. Of course, with a great enough number of accounts, this dialog would become taller than the screen. OTOH, if we stick it all in a GtkScrolledWindow?, it would be rendered tiny, unless we impose some minimum size request on it.

[nix_nix]

Ooops, I think s/pidgin_request/purple_request/g above.

How about a purple_request_fields named accumulator? This would be just like purple_request_fields(), but a string(?) would be used to identify the fact that these (groups of) fields are part of a larger (and possibly pre-existing) request. Then, different accumulator names would result in different (and fewer) dialogs.

Isn't this a little bit like the mini-dialogs in the buddy list?

[tfsmiles]

I've been observing the same problem, except that it is far more wide spread; both the chat windows and the buddy list window will grab focus when they open. Possibly other windows have the same problem (I'm willing to bet that it's all of them), but usually I'm interacting with Pidgin when they open so I haven't noticed.

I am running the sawfish window manager, and Pidgin/Gaim is the only application which has ever had this problem. I have tested this by spawning xterms and other GTK/Gnome applications and they don't steal the focus. There is something unique to Pidgin which grabs focus when it really shouldn't.

[eirik]

Hi,

any news on this? I also use sawfish, and agree that focus-stealing (especially for new conversation windows) is a problem -- and can confirm that this is uniqe to pidgin (in my experience).

I may be a bit lazy -- could any of the devs suggest where to start to look for this problem ? Is it perhaps possible to create a simple helloWorld-window using similar gkt-calls as Pidgin and try and figure out where the focus-stealing happens ? That, or just a hint where to start looking in the sources would be welcome.

[deryni]

There are a number of places in pidgin where we call gtk_window_present what that GTK+ function does depends on a number of things, not least of which are the NETWM/EWMH features your window manager claims to support, so it is entirely possible that either sawfish doesn't support the hint _present wants to use and so it falls back to attempting to steal focus or that it does support the hint and interprets the hint and gives pidgin focus. Either way there isn't much pidgin can do about it because that really is often the correct function to call. We used to call it much too often, we may still do so, but that is often hard to figure out. If you want to test my theory about gtk_window_present write a simple GTK+ application which creates a single window, sleeps, and then calls gtk_window_present on it, see what happens.

When I am home again and have access to a small test program I wrote I will attach it here, it simply sends the EWMH hint that gtk_window_present should be sending and as such should test whether this is sawfish giving focus or GTK+ taking it.

[bernmeister]

Any news on this ticket? Is it still an issue for people?

[psa]

I'm still seeing this with 2.4.3