From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010719 BuildID: 2001071904 Whenever those modal windows come up with some error (connection refused) , especially on mail, and some webpages, they take the focus and of course this is not what should happen Reproducible: Always Steps to Reproduce: 1.Get a connection refused modal window, in mail or in browser Actual Results: The modal window takes focus Expected Results: The modal window should NOT take focus This NOT a dupe of bug 77675, and this will NOT be resolved by bug 28586, which will only address modal windows in browser but not in mail Therefore i am filing this bug I dont know which component is the right one

Depending on a fix of bug 28586 , this bug could depend on that one

so... you have an application-modal window (that is, while that window is up you can't interact with the application). And you want it to not take focus? Doesn't that make the application _harder_ to use? Or am I missing something?

If my mail downloads each 5 minutes and i am browsing some pages, i dont want a modal window to switch me to mail and take focus away from what i was doing It's pretty annoying, and it happens to me no smaller than 20 times a day

One nice workaround would be to forget that modal window and put the "connection refused" dialog on the the status bar below Something like: Could not connect to server xxx.xxx.xxx after xx seconds

For those who haven't seen it yet - take a look at the discussion on bug 88810, especially comments Chris Brien 2001-07-03 16:02 Chris Brien 2001-07-04 06:35

Francisco: it sounds like there are two possible bugs here: 1) The connection refused window should not be modal (bad idea imo) or 2) There should be no connection refused alert at all for an automatic every-5-minutes check. I would file bug #2 as a bug on mailnews (after checking for dups, of course). That seems like the most promising approach to the real problem -- annoying popups out of nowhere. Once again, on Linux we currently do not have window-modal windows. We only have application-modal ones. Thus "Modal windows should not take focus when parent window does not have it" makes no sense, since _no_ window in the app can be interacted with if a modal window is up.

You may be right. Anyway, i filed this bug because of an underlying bug i think it's there somewhere. I have noticed that when i get this "connection refused" window, clicking on the get mail icon returns a connection refused window instantly. How can mozilla know i got a connection refused without even trying? I have 256k/64k and i really think something weird is happening. So i get all these connection refused windows, but i see that bug 77675 wont fix this, bug 88810 is kind of a meta tracking bug, and bug 28586 is aiming at changing modal windows for error webpages (like IE) So that leaves me with this issue, and making an error page inside the mail app is not a good idea imho. As i said, i dont _care_ if i get a connection refused modal window, i only care that i am browsing in mozilla and then sometimes i get that annoying window

Over to mailnews. This is not a general xp apps bug at all.

See bug 90485 for another axample of a modal window that shouldn't be allowed to pop-up "too far".

methinks this should go to mailnews frontend --but do punt as needed.

Sorry about the length of this comment; I didn't have time to make it shorter. Francisco, this bug is about focusing alert boxes. Until your most recent comment you didn't mention the problem with mail/news putting up a connection refused alert without even trying to check for mail, and even if that bug was fixed it wouldn't fix the focus problem for when mail was checked automatically or whatever. So you should really file a separate bug for that. Before the Internet came into widespread use, it was very uncommon to have windows churning away in the background doing unreliable things which might require putting up an alert. Even where we did, such windows were usually in a completely separate application, so the worst that happened was the application's icon flashing at you in the menu bar (bug 53345), and a little <floatingwindow> popping up in the top right corner of the screen without stealing focus from anything: +-+-----------------------------------------+ |O| [i] Netscape Communicator requires your | |:| attention. Please bring it to the | |H| front. | +-+-----------------------------------------+ However, in 1995 or something some bright spark decided that Mozilla's Web browser and mailer should be parts of the same application; and if they're the same application, then the above approach won't stop one Mozilla window stealing focus from the other. Narf. So I'm tempted to say that the solution is to make Navigator and Messenger separate executables. That would solve the `Connection refused' problem in this bug (as well as solving a *lot* of other UI problems in Mozilla), but it wouldn't solve the alert problem in general -- because one Navigator window might put up an alert which steals focus from another Navigator window, or one mail window might put up an alert which steals focus from another mail window. Bug 28586 (which does not block this bug) is a lucky method for getting rid of a large number of these alerts (lucky in the sense that we could only get away with it in a Web browser, not in any other app), but it won't get rid of all of them -- cookie alerts, proxy authentication alerts, and so on, will still be popping up to eat your lunch and steal your pets. Mac OS is in a similar situation to what Boris described for Linux; it knows only application-modal alerts, not window-modal ones (see also bug 57266). It's probably technically possible to make alerts and dialogs window-modal (rather than app-modal) on both platforms, so this bug goes to --> XP Toolkit/Widgets to find out. Even then, however, we'd have to roll our own notification mechanism to communicate the equivalent of `The window "MozillaQuestQuest" requires your attention. Please bring it to the front'. That would be ... fun.

[Reassigning to component owner, and fixing dependencies]

Actually, i filed bug 92195 a long time ago regarding this issue. I dont think it is dup of bug 93924, because that one deals with mozilla freezing on some network operations, which probably is dns resolving, which may be causing my mail problems, but still different bugs

This seems to have morphed into bug 65521

*** This bug has been marked as a duplicate of 65521 ***