88810 - Remove code that unnecessarily focuses/raises windows

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Tracking, defect)

Description

[Stephan Jaensch]

Based on the comments in bug 77675 and in n.p.m.seamonkey, there was general
agreement between the participants that window focusing should follow this rule
(quoting Niko Pavlicek):

"Windows should be able to steal focus only from their parent window.
A dialog appears in front of its parent window, but doesn't popup in front,
rather it should wait until the user focusses this dialog or its parent window."

The scope of this bug is broader than the one of 77675: It adresses not only the
problem of browser/mail windows stealing focus when document loading is
finished, but also simple information dialogs like "connection timed out"
popping up in front of all other windows (and stealing focus even across virtual
desktops). This is not desirable.

Really serious error messages which the user absolutely has to read right after
they occurred (no example comes to my mind for a browser/mail reader product)
could be made a child of the root window - if this is possible across all
supported platforms.

Please note that bug 77675 which describes a subset of these problems has 122
votes as of this writing. Assigning to saari since he has 77675 too.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Based on the original description this is a meta bug to track specific instances
of windows taking focus.

Moving to tracking component.

Comment 2

[Jacek Piskozub]

Why does this bug block 77675? Shouldn't it be the other way?

In short: does it really mean that before we solve a "subset of problems", we
have to solve the whole lot?

Comment 3

[Aleksey Nogin]

I guess the idea was that this bug asks for a bunch of focus code to be removed
and it may be easier to do just that than it would be to fix bug 77675 without
affecting the rest of the focus behaviour.

Comment 4

[Jacek Piskozub]

Alexey: That's exactly my point. If you can fix bug 77675 by fixing this,
creating a new bug was actually unnecessary.

Boris: On the other and, even if it is a tracking (or even meta) bug, the
blocking is plainly wrong. It should be the other way.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Aleksey: any proposal to remove focus code entirely should handle the following
things (at the absolute least):

1)  A different fix for bug 84232 (and other situations of that sort).  An
    application-modal preferences window is not a "fix", by the way.
2)  A way to deal with confirmation dialogs on application quit for minimized
    windows with unsaved content (email/editor)
Also, the summary and initial comment are incredibly misleading if this bug is
about removing the focus code altogether.

Jacek: Once people in this bug decide what the hell it's about we should change
the dependency accordingly. I did not do it right away because it would probably
get changed back, each change generating mail to all the people CCed on bug
77675 in the process--a waste of time and bandwidth.

Comment 6

[Stephan Jaensch]

Jacek: Yes, this was the intention. I thought it would be easier fixing this bug
than checking in a hack for bug 77675 and still having the general problem lying
around.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Resummarizing the bug to make it clear what the issue is.

Any responses on how to handle the situations I mention?

Comment 8

[Stephan Jaensch]

Regarding bug 84232: why is an application modal dialog not the fix? It is
precisely that what you want since there is no reason tying the preferences
dialog to a specific window. It has no connection whatsoever to that window
(besides being called from the menu of that window), so if you want it modal, it
should be application wide. The other possibility is to simply make a new window
which is not modal at all and explicitly focus it if the user should really
select "Preferences..." more than once.

I'm not saying focus switching code should be eliminated, but it should be
greatly reduced and every use of it should be thoroughly reviewed.

Regarding confirmation dialogs: They should not focus the corresponding windows.
Instead, a generic dialog should appear stating "There are unsaved changes.
Really quit?", leaving the user with the choice to abort and check for himself
if there is something left worth saving.

There are two possibilities: The user knew he has unsaved changes and wants to
quit anyway, so he hits "Ok" one time and exits. Or he didn't know there were
unsaved changes, then he should probably take a closer look anyway. Many
applications (e.g. the GIMP) do it this way and it is the right way to do it, IMO.

Comment 9

[timeless]

what a mess.  A bug w/ no blocks/depends doesn't belong in tracking. instead it 
belongs to nobody to be killed or adopted.

suggest wontfix.

Comment 10

[Dan M]

  Long-time Mozilla/Netscape people have seen this snake raised and killed it at 
least a dozen times. It's beyond getting old. You can't remove the ability to 
raise a window to the front and remain compliant with the JavaScript spec. Sure 
maybe the spec is broken, but if you want to work on that you'd more profitably 
spend your time lobbying ECMA or some such group.
  Given that the feature must be a capability of the browser, it'll be impossible 
to eradicate. Settling for control over eradication, there isn't much to be done 
that I can think of. Niko's quote at the beginning of this report is no doubt 
well-intended, but impractical. What about prompts from servers that will cut the 
connection if the user doesn't respond in a timely fashion?
  I don't see the big improvement if such prompts are attached to the already 
topmost window rather than the window to which they apply. You've still lost 
keyboard focus, and there is room for confusion in a dependent prompt attached to 
some random window that had nothing to do with it. How does one draw the 
distinction between truly important prompts which would be reparented, and not-
so-important pretenders which wouldn't? In a way that won't be abused by website 
programmers?
  You also need to worry about the effect reparenting has on the programming 
model. Windows are attached to their parent/opener through programmable 
interfaces. Mix that up and ask for subtle regressions. Perhaps if the designers 
of Navigator 2 had had Niko's sensibilities, this would be less of an issue. But 
now there are problems with expectations and backwards compatibility.
  I'm resisting the urge to close this bug "invalid" to see what ideas evolve. I 
think you've only scratched the surface of the related issues.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Stephan: there is no reason to make the prefs dialog modal.  The 'explicitly
focus it if the user should really select "Preferences..." more than once'
solution is the one we implement.  Changing summary once again to reflect the
fact that we only want to remove _most_ focusing code.

As for the confirmation dialogs, I disagree with you, as apparently do the
Mozilla UI designers.  Modeling our UI on the GIMP, which has tons of UI issues
is not the way to go.  It is far more preferable to have a confirm dialog for
each window with unsaved content, since the user may want to save some and not
save others... and most importantly because that's _faster_ for the user than
clicking "Abort" and then closing a bunch of windows by hand one at at time.

Comment 12

[kevin fisher]

I think the heart of this bug is that a number of every-day users find it
*extremely* annoying to be browsing along their merry way in a number of
seperate windows only to have the window they are currently devoting their
attention to disappear.  Not only is this bug annoying, but it can and no doubt
will confuse some users as to where their page went.  The situation only becomes
worse if one is typing something in a dialog box (email, bugzilla comments,
passwords, private information, etc.).

The very fact that the current behavior path mozilla seems to be taking is
different from any other program (at least in windows) in how it treats focus
states is going to confuse a number of people.  "What just happenned?  I've
never seen my computer do that before."
And there is ABSOLUTELY NO VALID REASON for it to do so.  What's wrong with
blinking in the task bar to let someone know if they're going to be disconnected
from a server if they don't respond?  Apparantly nothing if you ask the
programmers for any other piece of windows software.

I don't think JS compatability factors into it, either.  I don't hear any
comparisons to IE in stealing focus.  I don't know, maybe it does; I hardly use it.

Now, admittedly I don't know much about this 'modal' discussion.  I'm just
trying to argue the point of view of myself and a great number of other
frustrated mozilla users in that having mozilla decide with its infinite C
wisdom that an error or dialog box in some bottom-layer window is more important
to me that what I am currently working on is not only insulting to the user, but
it will only turn people off from using the software.

I am a netscape nut.  I love it.  I've loved it since the days where it was just
netscape and mosaic wars.  And I've loved most of what's been done with mozilla
so far.  But this bug is, though it may not be worded to the perfection some
desire, addresses an issue that could very well break my dependance on netscape
and mozilla.  Yes, I'm only one person, but I doubt people will flock to mozilla
just so they can say "damnit, I was working on that!" when their window
disappears because the FTP server he was trying to connect to on the side is
down, or perhaps because a picture from www.sluts-r-us.com finished loading.

Comment 13

[Asa Dotzler [:asa]]

Do you all realize that this _IS_ _A_ _BUG_. If you've been paying any attention
at all over the last 6 months you'd know that this (raising windows when the
page finishes loading) is a bug.  It has been fixed and regressed several times.
It is reported and will be fixed again.  A million comments saying that mozilla
shouldn't reaise a window when it finishes loading isn't going to make the fix
for 77675 come any sooner.  If anything all this spam sent to saari (every
comment you post sends email to the developer) is slowing progress not speeding
it up.  Please, for god's sake, take your opinions to the newsgroups. If any of
you actually understand how focus works in Mozilla and why (and not how you
think it should work) or if any of you have any code to contribute which will
improve the situation then please add it to the bug.  Beyond that all you are
doing is wasting peoples' time (people that could be fixing bugs). Please don't
reply to me in this bug. If you want to discuss this find me on IRC or in email
and stop spamming developers (unless you think that by driving them away from
reading bugmail and bugs you're going to see your issues addressed faster).

Comment 14

[Aleksey Nogin]

OK, I think I have something constructive to propose. I see the following ways
of reducing this problem:
1) Fix bug 77675 (this is something everybody seems to agree on)
2) Fix bug 28586 "use error page, not dialog for inaccessible pages". When that
bug is fixed, most error messages would be displayed in an existing window and
nothing will have to be raised anywhere.
3) I would imagine that these two bugs do _not_ cover all the cases where
windows are raised unnecessary. I believe that we should try to document all of
those (we can start in this bug and then file additional bug reports as needed).
This way we can have a meaningfull discussion of concrete issues instead of just
"Mozilla raises windows to often" (which is something I completely agree with,
but it's not getting us anywhere).

Comment 15

[Mike Schiraldi]

Making the prefs window application-modal could get very annoying. For example, 
earlier today i was looking into a problem with image blocking. I had the prefs 
window open to the "image permissions" section and went back to a browser 
window to check the URL of an image. Other times i'll be following instructions 
off a web page or email and need to have both working at once. Like the "please 
don't make anything pop up unless it absolutely has to" plea, i'd also ask: 
please don't make anything modal unless it absolutely has to be.

Comment 16

[Francisco León]

Uh.. guys?
user_pref("mozilla.widget.raise-on-setfocus", false); on prefs.js 
doesn't do what everyone wants?

Comment 17

[Robin Green]

Francisco - doesn't work for me. Tried editing prefs.js; mozilla deleted my
change. Tried creating users.js in same directory with that line; no effect.

Comment 18

[Robin Green]

I meant to say user.js not users.js. My comment still stands.

Comment 19

[Francisco León]

Make sure you edit the file when mozilla is NOT RUNNING! :-D
If i write a mozilla file while it is open, mozilla erases the change. That's
normal. But that line made wonders for me

Comment 20

[Chris Brien]

[Lots of text and possible _elegant_ solution]

Most error messages can be handled with a call to ShowModal() (or a cross-
platform equivalent). This blocks the parent window (the one with the error) 
until the dialog goes away. The dialog appears on top of the parent window. Not 
on top of the whole app.

Regarding bug 84232. The current implementation is good enough for now. A prefs 
dialog doesn't delong to just the one window, so shouldn't be modal. Nor does 
it need to be a fully-fledged window in it's own right. Rather, it is a window 
with no taskbar button (since it belongs to Mozilla), rather like a windows 
control panel. When the prefs dialog is selected from the menu, mozilla should 
find the currently open prefs dialog, and raise it.

The problem with focus is quite tricky when you sit and think about it. A 
normal application should never need to change focus between windows. But then 
add JavaScript and it's a whole new teapot of haddock.

JavaScript's .focus() methods are intended to be used to set the caret to DOM 
elements. They can be used to focus windows. Focussing its own window does 
nothing other than set the caret to whole HTML rendering area. Focussing 
another window brings it above the window that focussed it. But _not_ above any 
arbitrary windows. The only way a JavaScript should be above to bring itself 
above another window is if the _other_ window is a named child, opened by the 
JavaScript (I don't think it should be able to refocus it's parent window - 
correct me if I'm wrong).

So, we have a situtation where a window should be able to focus it's children. 
This is fine for when a new window is opened - the parent automatically focuses 
it's child (Should this be handled by the Window Manager?).

So yes, there is a need for focus. But not for error messages or modal dialogs. 
This is actually one of the reasons I hate MacOs, because its' version of IE 
does this.

Part of the problem in bug 77657 may be that all windows in Mozilla are named 
entities, accessible by JavaScript - quote "with the *first* browser
window I opened, i could not reproduce this". This suggests either that a 
parent window causes the focus for new windows, or that the window must be 
child to steal focus.



I think I have a solution for this (which solves bug 77657, bug 84232 and this 
one, and other more subtle ones), but I don't know the code very well, so I 
would have to ask someone else to implement it.  It involves remembering the z-
order for every window opened. When a new window is opened, it is given a z-
order higher than the window that opened it. Windows which are currently higher 
than the window than just spawned would be reshuffled to a higher z-order, 
preserving the arrangement. This way new windows will appear on top of the old, 
but wont appear on top of another window if the user has another window in a 
higher z-order. Calls to .focus() from JavaScript (or the C equivalent for code 
within Mozilla) will do something similar - bringing the .focus()'ed window on 
top of the calling one, while still preserving the z-order, and - most 
importantly - not bringing a window to the top if the calling window didn't 
have focus. A _nice_ side effect is that if you select the prefs dialog from a 
menu, the window with the menu will be focussed, and can then bring the prefs 
dialog above it, and visible . 
This would be extremely simple to do with a linked list of pointers to windows -
 essentially an array, but expandable and reorderable. 
Now, once you have the new z-order, you just find which windows are visible and 
paint them as usual.

The important point here is that when a window calls focus, the z-order of the 
new window is *one* (0x01 or I or Un) above that of the caller. Windows 
focussing themselves will implicitly no-op, moving themselves to one higher 
than themselves, reshuffling the z-order and returning to their original 
position.



If this is implemented properly, there will be no need to either get rid of or 
keep the dialogs that try to get attention by becoming topmost - they won't be 
able to in any case, and the code can be left.

<ignore>
Sorry if this sound a little out of phase - I've been writing and thinking at 
the same time (two things at once! never a good idea...)
</ignore>

Comment 21

[Boris Zbarsky [:bzbarsky]]

> A _nice_ side effect is that if you select the prefs dialog from a
> menu, the window with the menu will be focussed, and can then bring the prefs
> dialog above it, and visible 

Well... that doesn't actually follow if the windomanager is not doing raise on
focus.  Then all that may be visible of the window spinning up the prefs dialog
is a menu or part of a menu -- the rest may be hidden by other windows...

The overall idea seems worth considering, though.

Comment 22

[Chris Brien]

I don't think "stealing" focus is right at all. Windows shouldn't "steal" focus. 
Rather, they get "given" focus.

This is an important point. It means that a parent window can focus it's 
child, rather than the child asserting it's right to focus.  A new window 
opened by the currently focussed window will be given focus by the parent 
window. A new window created by a window which doesn't have focus, 
_won't_ be given focus.

IMO, focussing is the job of the window manager, error messages should 
be modal for their window, and no window should popup unless the user 
or the currently focussed window asks it to.

But since Mozilla seems to want to implement everything all by itself, it 
would then need to be able to track z-order of all open windows. Clicking a 
window should bring it to the top, and any window-modal dialogs would 
be on top of that. A window which requests itself to focus will no-op. A 
window that asks that another be given focus, will only give _its_ focus. 
The window being given focus appears above window giving focus, and 
_no other_. This would comply with the JavaScript spec, as technically any 
window which can find another (by name or by parent-child association) 
should be able to give it focus. Plus, the user wont get annoyed with 
windows popping up all over the shop.

For more details, see my comment on bug 88810.

Randall, I would happily have a dig at it. Point me to the right file and I'll 
hack till I drop.

BTW, I don't think newsgroup posts (or worse, email) are such a good 
idea for discussing things like this, as they will inevitably be lost in the 
mists of cyberspace by the time the code comes up for review or the bug 
crops up in another guise later on.

Which is easier, 
a) reading a long bugzilla page,
or b) trawling through a million newsgroup postings about communist 
imagery in the mozilla banners
to find important discussions like this?

Which is why I am posting this message to both this NG, and bug 88810.

Comment 23

[Francisco León]

This IS bug 88810 :)
Anyway... Has somebody tried the pref option i gave on past posts?
Because that one works... Or maybe the point of this bug is to remove the code
that makes focus because it just shouldn't be? I think it would be nice to have
both, but in particular i dont use it so i turned it off

Comment 24

[kevin fisher]

Francisco:
That prefs line appears to fix this bug in linux (or at least what I've seen of
this bug in linux).  But I also tried it in windows and it seemed to change nothing.
But hey, linux is good - now that I finally got mozilla to work with non-root users.

Comment 25

[kevin fisher]

Correction:
The prefs thing doesn't prevent dialog boxes (errors, etc) spawned from lower
mozilla windows from being raised above all windows (even non-mozilla) in linux.
And naturally, when you dismiss the dialog box, the spawning mozilla window gets
raised to the top and then has focus.
But hey, at moz. windows aren't taking over my desktop when they're loading
something.
Again, this only seems to work in linux (for me, at least).

Comment 26

[Joseph N. Hall]

Also note that the Image Manager and Cookie Manager windows have a peculiar
modality to them.  They prevent some interaction with browser windows.  I don't
see why these need to work this way.

Comment 27

[Francisco León]

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

Comment 28

[Aleksey Nogin]

91632 "Modal windows should not take focus".

Comment 29

[Dave]

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

Comment 30

[mike lima]

just tell me something please.

As I saw in all versions upt to the one I have (2001121203) is that an error on
mozilla also steals the focus.  Was that resolved too?

thanks!  :-)

Comment 31

[Aleksey Nogin]

It was not resolved - see bug 28586 for a hope to fix that.

Comment 32

[Dan Tobias]

I think bug 120155 belongs as a dependency of this... it's another bug involving
browser windows refusing to stay put in a minimized state.

Comment 33

[Chris Casciano]

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

Comment 34

[Mike Kaply [:mkaply]]

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

Comment 35

[Boris 'pi' Piwinger]

If this is a meta bug, there should be something about the "The operation timed
out when attempting to contact ..." alert, as described in the original report.
I cannot find a particular bug on that, though. It must be out there, so I don't
post a new one yet. Thanks.

pi

Comment 36

[Jesse Ruderman]

pi: that's bug 28586, "Should use error page and not dialog for inaccessible
pages".  But if it also happens with other alerts, you could file a new bug for
"javascript alert() should not steal focus from other windows".

Comment 37

[Boris 'pi' Piwinger]

Jesse, the bug you mention would solve the problem I describe. But my problem is
not the very existence of the alert but that it steels focus.

pi

Comment 38

[t4]

When I used -firebird and -thunderbird for the first time, I was pretty annoyed
by their behaviour to raise themselves to top position just because i clicked
into them. I like them nevertheless, but as someone who actually likes to work
with window managers that do _not_ raise a window just because I focused them I
am even  more surprised to find mozilla 1.6.5 doing the same thing which 1.0 did
not do.
As posted earlier, it is the job of the window manager to raise a window and not
of an application. Even if Ecmascript requires the ability to do so, I always
turn it off in the prefs.
enough rants, but this feature makes it really hard for me to keep my usual
style of work (i always have to bring the window i am working in back to top
even after a little scrolling)

Comment 39

[John Kinney]

This is the single most serious annoyance I have with Firefox.  Frankly, it is a near-debilitating problem that makes the browser almost useless to me for certain types of online research.

I do building code and accessibility consulting for a living.  As more and more regulations have come online, I find that I do the most efficient research and referencing online, especially when I have to cut-and-paste applicable sections of regulations into my reports.  When I'm writing a report, I commonly have a half-dozen or more reference websites loaded on Firefox in the background, many of which do automatic reloads from time to time.  In this situation, the incessantly distracting refocusing interruptions makes the browser all but unusable to me. 

I've worked out a couple of time-consuming workarounds, but it is very annoying to have the browser continuously display what to me is utterly useless behavior.  I'm not a programmer, but it's hard for me to believe there's not some simple way to install a switch in the code that would let a user choose between raising window focus or not on a reloading site.

I've also inserted user_pref("mozilla.widget.raise-on-setfocus", false) into my prefs.js file (I'm using WinXP on my work computer) unsuccessfully.

I really need a way to set Firefox to quietly reload pages in the background without affecting my work in other windows.  

Comment 40

[Steve]

Request severity be changed to 'Major'. Bug[aka; focus-stealing feature] causes extreme errors in Windows environment.

Step 1; Under Windows XP, I had minimized Firefox, and was attempting to drag a folder out of a zip file.
Step 2; For some reason, Javascript or otherwise, Firefox had opened a window.
Step 3; I noticed that Firefox not only brought up the new window, but the old window too.
Step 4; My "Drag" operation froze while my mouse cursor was over the new window.
Step 5; Destroyed the "Drag Process" using the task manager. (Alt+Ctrl+Del)
Step 6; I minimized the main window, and closed the firefox window that had popped up and froze my drag process.
Step 7; Windows Explorer[taskbar/desktop] closed too, at the same time.

Personal note; I have been under the impression for the last ten years that Focus Stealing is NEVER a good idea. I don't know who thought of it, but listen; Some of us Multitask. Some of us have things to do on our computer, besides sitting around, holding the hand of every program that feels that it's important enough to pop up while we're trying to do things that are not related to that program. So, a new window was openned in the browser. It's not the end of the world. However, if I'm trying to unzip a zip file in the background, or balance my checkbook in my spreadsheet software before heading out the door to the bank, these are time critical operations, and I don't appreciate every little thing popping up, stealing my focus, killing my "Mouse Drag Process", and causing Explorer to crash. I've tried all the Alternative Desktops. Yes, they suck. I'd rather hex-edit my system libraries to ignore all non-SCR-file-based requests for Focus that are not tied to me personally clicking on the taskbar. However, until I am experienced enough to do so, I'll just have to file annoying bug reports like this one, with "steps to reproduce" that probably don't help too much.

Comment 41

[Ralph Loader]

Conceivably, there could be security concerns with changing focus when it is not explicitly requested by the user:  e.g., if the user is typing a login into another window, firefox steals the focus, the user does not notice, and types their password into an attackers web-page instead.

Is this a realistic concern, or can we be confident that it would be impossible for a web-site to exploit?

Comment 42

[John David Galt]

For some of us at least, it happens often enough by accident that there ought to at least be a preference setting to prevent Mozilla from EVER seizing the focus.

Comment 43

[John Kinney]

I see that others have been experiencing the same problem that has made Firefox unusable for me in much of my work environment (see Comment #39).  Approximately two weeks after Comment #39, I finally switched my business use to Opera, which has other serious deficiencies, but does not have the incessant focus stealing bug.  I wish I were sufficiently technically trained to help fix the code on this one.  I do extend my gratitude to those who are reopening the issue.  Let me know if there is any way I can help.

Comment 44

[Tony Tovar]

Personally, I have lots of problems with IE6 stealing focus but *never* with Firefox.  

Can you new reporters create a specific test-case, i.e., open web page X, then minimize, wait 3 minutes and --voila-- it pops back up?!  It may very well be that there is a specific javascript command(s) in those web pages that is causing the problem.  It also may be something specific to your combination of OS and apps, and not something FF is doing wrong (though that doesn't mean it isn't something they might be able to watch for).  Ideally, I think you should create a new bug for your specific case, provide full details and at least one test-case, and then mark it as Blocked By this bug (88810).

As an example of how Firefox *properly* handles javascript, I just tried loading the salon.com homepage, scrolled half-way down, then minimized.  When I checked back a minute later, it was back to showing the top of the page -- this is because Salon.com forces a full page-refresh every minute or two (aargh).  Point is, this automated refresh did *not* cause FF to steal focus.

Comment 45

[John Kinney]

(In reply to comment #44)

> Can you new reporters create a specific test-case, i.e., open web page X, then
> minimize, wait 3 minutes and --voila-- it pops back up?!  It may very well be
> that there is a specific javascript command(s) in those web pages that is
> causing the problem.  

Go to Weather Underground (wunderground.com) and pick a location for a weather forecast (I commonly use my location in Garner, NC).  Wait for the page to load completely, then minimize the Firefox window.  When Weather Underground updates the forecast, Firefox will grab window focus.  Opera does not.

There are many other sites that work the same way.  Right now I'm using Opera for most of my stuff, but I'll try to switch back to Firefox and get those for you.

> It also may be something specific to your combination of
> OS and apps, and not something FF is doing wrong (though that doesn't mean it
> isn't something they might be able to watch for).  Ideally, I think you should
> create a new bug for your specific case, provide full details and at least one
> test-case, and then mark it as Blocked By this bug (88810).

I'm using Win XP SP2 on a Compaq Presario R3000.  Firefox 2.0.0.7, nothing odd for applications.  Commonly running MS Word and Excel or OO Writer and Calc (sometimes all 4); usually Opera and Pan minimized, and multiple instances of Adobe Reader (more recently Foxit Reader). 
 
> As an example of how Firefox *properly* handles javascript, I just tried
> loading the salon.com homepage, scrolled half-way down, then minimized.  When I
> checked back a minute later, it was back to showing the top of the page -- this
> is because Salon.com forces a full page-refresh every minute or two (aargh). 
> Point is, this automated refresh did *not* cause FF to steal focus.

I just tried this on my system and got the exact same result.  Return to top and no focus grab.  So apparently it's a matter of *how* a website refreshes, not the refresh itself?

Regards, John KINney

Comment 46

[Martin Stubenschrott]

I can confirm that bug, also in my experiments with firefox3 beta1, even content.focus() brings the window to the front. What do we have window.focus() for? I think that should focus the window, but not content.focus();

Even more annoying is 

firefox -remote "openurl($URL,new-tab)"

focusing the window and stealing my focus. So it's impossible to use external feed/mail reader if you ever want to open more than 1 url without reading them immediatly.

Comment 47

[Jesus Cea]

See bug 406167.

Comment 48

[dpk]

I can confirm this bug as well, and add another potentially interesting note. Firefox 3 Beta 4, Linux build (downloaded, not built from source).

I run Debian Etch with Metacity. I keep Firefox in workspace 2. If I open a link in workspace 1, by clicking it in gnome-terminal, or just running "firefox http://uri", or "firefox -remote 'openurl(...)'", the whole Firefox window moves over to my current workspace (1). FF2 did not do this.

I'm not even sure where to begin looking for this in the code, so I don't think I can come up with a patch.

Comment 49

[Raphael Kimmig]

That one bugs me too, on Debian/Lenny:
FF 3 RC1 is raising window _and_ grabbing keyboard focus on every click.
This didn't happen in FF 2 and renders it completly useless for me.

Regards, raf

Comment 50

[BMO Automation]

Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE.
If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work
being tracked. The Core: Tracking component will no longer be used.