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.
Based on the original description this is a meta bug to track specific instances of windows taking focus. Moving to tracking component.
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?
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.
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.
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.
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.
Resummarizing the bug to make it clear what the issue is. Any responses on how to handle the situations I mention?
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.
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.
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.
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.
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).
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).
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.
Uh.. guys? user_pref("mozilla.widget.raise-on-setfocus", false); on prefs.js doesn't do what everyone wants?
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.
I meant to say user.js not users.js. My comment still stands.
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
> 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.
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
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.
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).
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.
*** Bug 90485 has been marked as a duplicate of this bug. ***
91632 "Modal windows should not take focus".
*** Bug 99533 has been marked as a duplicate of this bug. ***
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! :-)
It was not resolved - see bug 28586 for a hope to fix that.
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.
*** Bug 137015 has been marked as a duplicate of this bug. ***
*** Bug 126906 has been marked as a duplicate of this bug. ***
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
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
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)
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.
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?
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.
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.
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.
See bug 406167.
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.
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
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.