Firefox jumps into the foreground when Quick Find bar disappears

REOPENED
Unassigned

Status

()

Toolkit
Find Toolbar
P5
minor
REOPENED
11 years ago
a year ago

People

(Reporter: Imre Péntek, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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
Component: Search → Find Toolbar / FastFind
QA Contact: search → fast.find
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.
Summary: firefox jumps into the foreground when search finishes → Firefox jumps into the foreground when search bar disappears
Which window manager are you using?
(For reference, I'm using GNOME.)
(Reporter)

Comment 3

11 years ago
I use IceWM

Comment 4

11 years ago
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
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk

Comment 5

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

Updated

11 years ago
Summary: Firefox jumps into the foreground when search bar disappears → Firefox jumps into the foreground when Find bar disappears

Comment 6

11 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID

Comment 7

11 years ago
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

11 years ago
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.
(Reporter)

Comment 9

11 years ago
I don't think so that it is reasonable to force the firefox window into the foreground, when the user switched to another application.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 10

11 years ago
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. 
(Reporter)

Comment 11

11 years ago
Then place a config option into the preferences.

Updated

10 years ago
Duplicate of this bug: 379839

Comment 13

10 years ago
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.

Updated

10 years ago
Duplicate of this bug: 391415

Updated

9 years ago
Duplicate of this bug: 426534

Comment 16

9 years ago
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.
Summary: Firefox jumps into the foreground when Find bar disappears → Firefox jumps into the foreground when Quick Find bar disappears

Updated

9 years ago
OS: Linux → All

Updated

9 years ago
Blocks: 88810
Duplicate of this bug: 430546
Duplicate of this bug: 433158
Duplicate of this bug: 440821

Comment 20

9 years ago
> 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.
(Assignee)

Updated

9 years ago
Product: Firefox → Toolkit

Comment 21

9 years ago
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

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

Updated

8 years ago
Duplicate of this bug: 466412

Comment 24

8 years ago
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
Duplicate of this bug: 496869

Comment 26

8 years ago
> 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

8 years ago
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).

Updated

8 years ago
Duplicate of this bug: 522936

Comment 29

6 years ago
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.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.