User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20060404 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20060404 Firefox/220.127.116.11 I use search-when-typing, but maybe works without this too. I search for a string, then I switch to an other application. some seconds later firefox jumps in foreground and takes the focus when search finishes. Reproducible: Always
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8) Gecko/20051111 Firefox/1.5 - Build ID: 2005111116 WFM. When the search bar disappears after the timeout, Firefox just flashes in the taskbar for my attention, which is a perfectly reasonable thing to do.
Which window manager are you using? (For reference, I'm using GNOME.)
I use IceWM
I've hit this too, and it's rather annoying (even if it is just the window blinking). I don't know if this is something we can fix -- e.g. not sending a "notify" event when the bar disappears -- or if it's something the window manager handles. For what it's worth, on Windows the behavior is as follows: - minimize the window, then wait for timeout: windows is unminimized and brought into focus - only focus another window, then wait for the timeout: window is not focused, nor does it blink the the taskbar
*** Bug 328467 has been marked as a duplicate of this bug. ***
We call focus() on various things which ends up calling nsWindow::SetFocus, which calls GetAttention(), which does this. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/gtk2/nsWindow.cpp&rev=1.186&mark=712-715#692 This action can be controlled by the pref. "mozilla.widget.raise-on-setfocus". If I set that to true, this bug doesn't happen anymore. I think the whole way we go about doing this in GTK is slightly flawed, but that's another bug. I think this bug is INVALID, though, since this is the expected behavior and it's configurable.
Isn't the bug here, though, that the find bar disappearing shouldn't cause the window manager to be notified at all? I don't see any reason that a user would care about the bar disappearing if they're currently using a different window.
Well, it's not the disappearing, it's the focusing. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/components/typeaheadfind/content/findBar.js&rev=1.48&mark=584,586,588,590,595#565 And it makes sense to focus content after the find bar disappears, so it's a matter of "do we notify the user on something getting focused", not "do we notify the user on the find bar hiding". The hiding of the widget is not what causes this to happen.
I don't think so that it is reasonable to force the firefox window into the foreground, when the user switched to another application.
Well the behavior all makes sense from a code perspective. It's just from a user perspective it doesn't make sense. ;) I guess we need some way for some focuses to get the user's attention and others not to.
Then place a config option into the preferences.
I've got a similar problem: When Firefox loads an old session with several windows, they will jump to the foreground randomly. This is especially annoying when you're about to type passwords into a dialog or when you switch desktops on Linux. If Firefox is inactive, it should not try to capture the focus. Same if a dialog is open.
My test case from the other bug: Firefox 18.104.22.168 on Windows XP: - Close all Firefox windows. - Open Firefox either by opening a Windows web shortcut or by starting Firefox when you have a home page defined. It will not work if you start Firefox and it's set to start with a blank window. - Start typing to activate Quick Find. - Switch to something else, such as by Alt-Tab. - When the quick find bar disappears in a few seconds, Firefox will steal the focus back. This only seems to happen the first time, as in subsequent attempts it will leave the focus alone. It also doesn't work if you start with a blank page because giving focus to the URL bar before doing this seems to correct it. It looks like something just isn't initialized correctly but eventually it will get into the correct state. Also changing "Find" to "Quick Find" in the title to make this easier to search for.
> Well the behavior all makes sense from a code perspective. Right, right. But users don't care about code perspective. For _user_ this looks dumb --- there is absolutely nothing interesting in quick find toolbar disappearance. Why should user be notified? User convenience is kinda more important than code.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/2008071816 Ubuntu/8.10 (intrepid) Firefox/3.0.1 I am enough of a coder (well, php and the likes, meh) to dig this. Yeah, sure. When the find bar disappears we have to focus on something. Changing focus raises the Window. I know that writing exceptions for big rules like this can be a very bad idea and introduces bugs. But this is driving me absolutely and totally nuts. I have to train myself to hit "escape" after a quick find. or maybe to press CTRL+F instead of / Is there a preference for dumbing down the over smart quick find or for mapping regular find-in-page to /? Because as much as this is bothering me, I'd rather not break ALL activate-on-focus events just for the sake of one extra keystroke.! Please fix this. Quick find in page can (rightly) find things within form inputs. If I switch task to an instant messenger after finding something in a form input, it will steal focus and cause me to accidentally submit the form. So it's not just an aesthetic issue: this can arguably result in loss of data. ;-) Just my two cents, I hope it wasn't too unhelpful.
How about set pref "mozilla.widget.raise-on-setfocus" to false by default?
Could the subject be changed to: Firefox jumps into the foreground / steals focus when Quick Find bar disappears please? This would make this bug easier to find and avoid some duplicates (when the Firefox window is already in the foreground, one just sees the focus problem).
With Firefox 3.6, 4.0, 5.0, I can no longer see gdk_window_show_unraised() be called when Quick Find disappears and Firefox doesn't have focus. I think it might be the change of http://hg.mozilla.org/mozilla-central/rev/cabb8925dcd3 However I only tested it on Solaris.
I've just tested Iceweasel 5.0 and earlier Firefox 3.6 - the bug seems to be gone (Debian with Openbox). And it's probably true it disappeared between 3.5 and 3.6 as in 3.5.19 it's still there but not in 3.6.