More stuff found, with the help of Mike Hommey. We are now debugging Firefox 3.5.8 with gdb, breaking on XSetWMHints.
After using the move-to-another-head trick to work around the problem, XSetWMHints is not called *at all*. Loading a link before moving the window back to head 0 restores the focus stealing behaviour, and XSetWMHints is getting called again. This can be reproduced as many times as desirable. Fun, isn't it? It seems that every time the focus is lost XSetWMHints is called via update_wm_hints from nsWindow::SetUrgencyHint. This happens six times for each click, but only the first four, sometimes the first five, change the focus. Only the first two calls come from command-line handline, the other are in response to the GTK focus_in event. The curious thing is that nsWindow::SetUrgencyHint is called with state=0, which causes gdk_window_set_urgency_hint to be called *clearing* the flag[0] 0. http://developer.gimp.org/api/2.0/gdk/gdk-Windows.html#gdk-window-set-urgency-hint In fact, wmhints->flags is 0x67 throughout, which is InputHint|StateHint|IconPixmapHint|IconMaskHint|WindowGroupHint, so I think we can totally forget about the urgency hint. It might be that I am getting confused about firefox vs. xulrunner. I need to go away for a few days, but upon return I shall continue debugging with the xulrunner source compiled with debug symbols! -- .''`. martin f. krafft <madd...@d.o> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)