// Set focus to the window
- if (gRaiseWindows && aRaise && toplevelWidget &&
+ if (0 && gRaiseWindows && aRaise && toplevelWidget && !GTK_WIDGET_HAS_FOCUS(toplevelWidget) && owningWindow->mIsShown && GTK_IS_WINDOW(owningWindow->mShell)) gtk_window_present(GTK_WINDOW(owningWindow->mShell));
and built new packages, but the problem remained. However, I found
a couple of curiousities. I have three heads one two graphics cards,
and I use Zaphod mode to put them all next to each other. head 0 is
on GPU 0, and heads 1&2 are on GPU 1.
1. the focus is never stolen when the Firefox window is on heads
1&2, not even if the link is clicked on another head.
2. if I move the window from head 0 to head 1 and back, then it no
longer steals focus, not even if the click is on a separate head.
3. if I move the window from head 0 to head 1, click a link, and
move it back to head 0, then the focus stealing happens again.
I then went back to investigate these three points with the original
Firefox packages, i.e. without the above patch, and the behaviour is
identical.
Then I investigated the urgency hint, using xprop -spy: I started it
in a terminal, then X-pasted a link into that terminal and clicked
it. I did this to avoid changing focus with the mouse while testing.
There was nothing in the output of xprop -spy mentioning an urgency
hint. I did verify that xprop -spy shows the urgency hint, using
URxvt.urgentOnBell and echo -e '\a'.
This is starting to feel a bit like a riddle. For me, (2.) above is
an okay workaround at the moment, but it really seems like the
Firefox code needs some cleaning.
First, how does this bug report relate to Mozilla bug #263553? Isn't it a duplicate?
I just posted the following to http:// bugs.debian. org/486570, but I found no way to update this bug report.
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:
--- a/widget/ src/gtk2/ nsWindow. cpp src/gtk2/ nsWindow. cpp :SetFocus( PRBool aRaise)
owningWindow ->mContainerBlo ckFocus = PR_TRUE;
+++ b/widget/
@@ -1406,7 +1406,7 @@ nsWindow:
// Set focus to the window
!GTK_WIDGET_ HAS_FOCUS( toplevelWidget) &&
owningWindow- >mIsShown && GTK_IS_ WINDOW( owningWindow- >mShell) )
gtk_ window_ present( GTK_WINDOW( owningWindow- >mShell) );
- if (gRaiseWindows && aRaise && toplevelWidget &&
+ if (0 && gRaiseWindows && aRaise && toplevelWidget &&
and built new packages, but the problem remained. However, I found
a couple of curiousities. I have three heads one two graphics cards,
and I use Zaphod mode to put them all next to each other. head 0 is
on GPU 0, and heads 1&2 are on GPU 1.
1. the focus is never stolen when the Firefox window is on heads
1&2, not even if the link is clicked on another head.
2. if I move the window from head 0 to head 1 and back, then it no
longer steals focus, not even if the click is on a separate head.
3. if I move the window from head 0 to head 1, click a link, and
move it back to head 0, then the focus stealing happens again.
I then went back to investigate these three points with the original
Firefox packages, i.e. without the above patch, and the behaviour is
identical.
Then I investigated the urgency hint, using xprop -spy: I started it
in a terminal, then X-pasted a link into that terminal and clicked
it. I did this to avoid changing focus with the mouse while testing.
There was nothing in the output of xprop -spy mentioning an urgency
hint. I did verify that xprop -spy shows the urgency hint, using
URxvt.urgentOnBell and echo -e '\a'.
This is starting to feel a bit like a riddle. For me, (2.) above is
an okay workaround at the moment, but it really seems like the
Firefox code needs some cleaning.