Iceweasel rudely interrupts my session and switches the window
manager to it whenever it loads a URL or opens a dialog.  This means
I'm unable to minimise all its windows whilst loading a session
(usually about 100 tabs in 10 or so windows), like I could with
Iceweasel 2.  Even worse, if I'm entering the password manager's
master password, other Iceweasel windows steal the focus while I'm
trying to enter the password - not just rude, active dangerous!

Window manager is fvwm 2.5.26, if that matters.

ever since upgrading from 2 to 3, iceweasel keeps stealing focus and
warping the mouse pointer.

this is not just annoying, this is a serious security issue, as it
regularly happens to me that I enter some password when the icewesael
window is unmapped(!) and just before pressing return I find myself typing
the password into the login field of the login box.

This is not just annoying (one has to unmap the iceweael window, move
the cursor back to the original window), it is also a rather disastruous
security issue, as:

a) the password will be clearly visible to anybody standing around
b) if one types quickly, the password will be sent in cleartext to the remote site(!)

please reconsider the improtance of this bug, without the security issues,
this would be just annoying, but as it is, this is outright dangerous
- iceweasel basically acts like an evil application trying to steal
credentials.

after some analysis, I found out that this focus-stealing problem is
caused by iceweasel blatantly abusing the urgency hint.

the urgency hint is defined as (per icccm): The UrgencyHint flag, if set
in the flags field, indicates that the client deems the window contents to
be urgent, requiring the timely response of the user.

and this is of course not true for all the uses that firefox has for it
(as obviously, a new tab or a login dialog certainly do not need a timely
response at all).

unfortunately, this ruins all the other valid uses for urgency hints.

After reading what James wrote[0], I went to investigate this a bit.

0. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486570#15

First, I found the single call to gtk_window_present in the Firefox
source and disabled it:

found 478981 3.6-0preview1
thanks

Here's some additional information. Since I now have a way to switch
focus-losing on and off (moving to another head and back, clicking
a link in between or not), I compared xprop -spy output. This is the
diff:

  3,14d2
  < WM_HINTS(WM_HINTS):
  <               Client accepts input or input focus: True
  <               Initial state is Normal State.
  <               bitmap id # to use for icon: 0x1800030
  <               bitmap id # of mask for icon: 0x1800031
  <               window id # of group leader: 0x1800001
  < WM_HINTS(WM_HINTS):
  <               Client accepts input or input focus: True
  <               Initial state is Normal State.
  <               bitmap id # to use for icon: 0x1800030
  <               bitmap id # of mask for icon: 0x1800031
  <               window id # of group leader: 0x1800001
  19,24d6
  < WM_HINTS(WM_HINTS):
  <               Client accepts input or input focus: True
  <               Initial state is Normal State.
  <               bitmap id # to use for icon: 0x1800030
  <               bitmap id # of mask for icon: 0x1800031
  <               window id # of group leader: 0x1800001

So in the case when Firefox loses focus, WM_HINTS are being set
(although no urgency flag), while they are not at all touched/set
when focus is maintained.

And while I am at it, the problem is the same with Firefox 3.6.

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!

Hello Martin,

any news on this bugreport (icedove related)?
Did this also happen in current versions? Or could this report closed
for the icedove part?

Regards
carsten

also sprach Carsten Schoenert <c.schoenert@t-online.de> [2012.11.01.2028 +0100]:

It's still present, and it's still annoying. Icedove, Iceweasel, all
the same.

This issue has bothered me for a long time. Finally, I found a
solution [1] while searching the web. In address bar, enter
"about:config"; this takes you to advanced settings page. After
clicking on the "I'll be careful, I promise!" button, the settings
page loads. Set "browser.tabs.loadDivertedInBackground" to true by
double clicking. Reloading iceweasel enables the changed setting.
Worked for me.

Cheers,
John

[1]
http://www.techsupportalert.com/content/how-stop-firefox-stealing-window-focus.htm

Hello John,

are you willing to write a little tip to the wiki?
https://wiki.debian.org/Icedove#Tips

I don't think we will change the default behavior of this setting, at
least it may be possible to add a Debconf functionality to change this
while installation or a dpkg-reconfigure.

@Martin
What do you think? Can you please recheck the behavior of this bug with
the change of this setting? Thanks.

Regards
Carsten

also sprach John Vogel <jvogel4@stny.rr.com> [2013.08.09.2324 +0200]:

Setting browser.tabs.loadDivertedInBackground substantially changes
the behaviour of the browser, which I am not willing to accept.
I don't think it's reasonable to expect users to change their
browsing habits just because Mozilla doesn't behave properly wrt
urgency hints.

On 08/10/2013 02:38 AM, Carsten Schoenert wrote:
 > Hello John,
-snip-
 > are you willing to write a little tip to the wiki?
 > https://wiki.debian.org/Icedove#Tips
 >
 > I don't think we will change the default behavior of this setting, at
 > least it may be possible to add a Debconf functionality to change this
 > while installation or a dpkg-reconfigure.
 >
 > @Martin
 > What do you think? Can you please recheck the behavior of this bug with
 > the change of this setting? Thanks.
 >
 > Regards
 > Carsten
 >
I'll write a tip for the wiki. Should I send the text of the tip to you?
I don't have write access.

On 08/10/2013 02:39 AM, martin f krafft wrote:
-snip-
I see your point. I've spent a little time using xtrace to try to
understand the X11 calls occuring at or near the time of the focus
change. Until I can better filter out unrelated traffic, I don't see
that xtrace is going to much help. I go back at it when I have time.

Regards,
John

Hello John,

I would prefer you write the hint by yourself to the wiki, it isn't so
difficult, just register to the wiki and you can write. ;)
And it's a wiki, so if everybody can change it by it's needs. Another
point for me that you should write the entry is that only you can
exacatly describe the workaround.

That would be great if you can provide more infos to that issue! So if
you find some time to digg deeper into it ... we happely take any help.

Regards
Carsten

KINDLY VIEW ATTACHED FILE FOR FURTHER INSTRUCTIONS.

MUTUAL BENEFIT BUSINESS

-- 

MUTUAL BENEFIT BUSINESS.

PLEASE DONT IGNORE.

VIEW ATTACHED FILE.

PAUL DAVIS