332990 - Firefox jumps into the foreground when Quick Find bar disappears

Status: REOPENED

(Toolkit :: Find Toolbar, defect, P5)

Description

[Imre Péntek]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060404 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060404 Firefox/1.5.0.1

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

Comment 1

[Philip Withnall (unavailable)]

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.

Comment 2

[Philip Withnall (unavailable)]

Which window manager are you using?
(For reference, I'm using GNOME.)

Comment 3

[Imre Péntek]

I use IceWM

Comment 4

[Adam Guthrie]

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

Comment 5

[Adam Guthrie]

*** Bug 328467 has been marked as a duplicate of this bug. ***

Comment 6

[Adam Guthrie]

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.

Comment 7

[dolphinling]

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.

Comment 8

[Adam Guthrie]

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.

Comment 9

[Imre Péntek]

I don't think so that it is reasonable to force the firefox window into the foreground, when the user switched to another application.

Comment 10

[dolphinling]

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. 

Comment 11

[Imre Péntek]

Then place a config option into the preferences.

Comment 13

[Aaron Digulla]

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.

Comment 16

[Greg Valure]

My test case from the other bug:

Firefox 2.0.0.13 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.

Comment 20

[Paul Pogonyshev]

> 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.

Comment 21

[Chris]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) 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.

Comment 22

[Boying Lu]

How about set pref "mozilla.widget.raise-on-setfocus" to false by default?

Comment 24

[Martin von Gagern]

Just because this got me confused at first: "mozilla.widget.raise-on-setfocus" isn't listed in the preferences, you have to manually add it as a boolean value set to false. After that, you have to restart Firefox, as it won't take effect immediately. With those settings in place, it looks like a feasible workaround for now, but only for experienced users.

(In reply to comment #22)
> How about set pref "mozilla.widget.raise-on-setfocus" to false by default?

As I haven't ever encountered a case where I'd actually want FF to notify me, I'm in favor of this. I fear that otherwise some web pages might some day start switching focus around by JavaScript to gain attention.

(In reply to comment #6)
> We call focus() on various things which ends up calling nsWindow::SetFocus

I haven't been able to follow that part in mxr. Where does the JavaScript call to the focus method get turned into the C++ call to nsWindow::SetFocus? As SetFocus provides a boolean argument to tell whether or not the window should be raised, maybe it would be possible to optionally allow for such an argument in focus as well. That way, findBar could focus without raising the window.

Useful link: http://mxr.mozilla.org/firefox/search?string=raise-on-setfocus

Comment 26

[nickers]

> As I haven't ever encountered a case where I'd actually want FF to notify me,
> I'm in favor of this. I fear that otherwise some web pages might some day start
> switching focus around by JavaScript to gain attention.

They already do. Luckily, in Firefox, dom.disable_window_flip is on by default.

Comment 27

[Vincent Lefevre]

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).

Comment 29

[Ginn Chen]

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.

Comment 30

[Marcin Szewczyk (:wodny)]

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.

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 10 duplicates.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 32

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.