See bug 28467 for related discussion. When a page loads, the browser window steals focus from any other windows that may be in front of it at the time. This appears to happen regardless of the content of the web page. Naturally, this is a very severe problem on slow or congested links.

Forgot to mention, I'm currently seeing this on 2001042108, and the problem dates back at least to NS6.0PR1, which was the first version of Mozilla I tried.

Thanks for filing this. (I had closed that other bug since it had become too fragmented, and it would be more direct to file a specific (new) bug). Is there a particular set of steps that is more likely to reproduce this condition.

The only real trick is that it appears you have to shift the focus to another window before the first paint occurs in the content area. Choking your connection with a big download helps. One technique I've used is to reproduce it more often is to Win+M (minimize all windows) after selecting the link/bookmark/whatever. When it steals the focus, the window will restore itself.

This happens on Linux too. Assigning to saari, ccing blizzard. Keyword fun.

This should be fairly easy to reproduce. Go to the computer with the analog modem (you have to have at least one lying around somewhere). Launch Mozilla. Open a new browser window (you should now have 2 windows open, window A and window B). Wait until the homepage loads in both windows. Type in a URL in window A and press return. Quickly, before that page starts to load, switch to window B. As soon as the page in the window A starts to load, that window will be brought to the front, covering up window B. This bug makes it impossible to browse with multiple windows since you'll always have windows jumping to the foreground, hiding the window(s) you were working with. You have to wait until the page starts to load (i.e., the content is first drawn into the new window) before switching to a different window. Note that this has nothing to do with the page's contents (namely, textbox.focus()) - it happens with *all* pages. On Macintosh, there is no way (in this case) for an application to steal focus from another application, so I think that aspect of this bug should be filed separately.

Most of the cases for this behavior have been fixed. I need specific pages that demonstrate this.

Here are some samples: http://www.news.com/ http://www.tech-report.com/ All BugZilla bug pages appear to be affected. http://gcc.gnu.org/lists.html

On Mac OS, this happens for all pages. It has nothing to do with the content of the page being loaded. Is that different from what other people are seeing?

I just tried this on a fresh tree on my Mac G4 500 and none of the pages in this bug or others steal focus anymore. What speed machine are you running on? Maybe there is a race condition that is still present.

resolving as wfm, please reopen if you find a reproducible case in a current build.

Reopening. Very simple steps to reproduce: 1) Get a Unix system. 2) Set your windowmanager not to raise on focus (that way a window can have keyboard focus while being below other windows). 3) Pick a bugzilla bug. 4) Type some comments in the description 5) Lower the window so it's below other windows but the "Commit" button is visible 6) Click "Commit" 7) Watch the window raise itself just as the page load begins.

I also see this going to the "Show all checkins" page off of Bonsai, btw. Same steps 1) and 2). Then: 3) Load tinderbox. 4) Make sure the window with tinderbox loaded is not on top and that the "Show all checkins" link is visible. 5) Click that link 6) Watch the window raise itself as page load starts.

test

Doesn't the click on the commit button automatically bring the window forward? Does for me on sawfish. This bug is about the page coming forward on end load, not when you click.

For me (fvwm2) it does not. The window does not come forward until the new page has started to load. At least it does not raise itself till noticeably after the current page has been blanked out. If that should be a separate bug, I will gladly file one.

blizzard, I don't seem to be able to get my linux box in the proper state to reproduce this. Can you?

I also see this with Afterstep, btw. Using SloppyFocus with both windowmanagers.

This bug was originally filed on NT. Please don't mark it Linux-only.

It happens on Win98 too. Should revert the OS to ALL...

saari, I belive sawfish has a keybinding in place to do that raise on click stuff (check the key bindings) Another way to reproduce find a site that is a bit slow on the connections. Click on a link, enter a url, minimize the window, and watch it raise itself when the page starts to load. This is a bit harder to trigger though and is very dependant on the speed of your connection.

Back to All/All. I'm seeing this on Mac OS X. FWIW, my setup is Mac OS X 10.0.1, G4 533 MHz, cable modem. Steps to reproduce: 1) Get FizzillaCFM. 2) Load http://www.mozilla.org/ 3) Command-click a link 4) When the new window appears, immediately click the old window. 5) Wait. 6) The bug does not show up every time. If the bug didn't show up, repeat steps 3 thru 6 with the next link.

Okay, I finally reproduced this, but I had to try pretty hard and only then when using the context menu... this isn't a catfood issue anymore IMO.

Sorry, my comments were from an earlier (4/20) build. No longer seeing the issue. Whoever fixed this deserves to be the resident deity for a week.

Have you tried it with the example URLs I posted? Is it completely fixed on the Mac? This seems to happen for about 40% to 50% of pages on win32 with current builds.

I was testing on Mac, I'll try win32. Yes, I was using your urls. Are you seeing it 40-50% of the time when using the context menu and moving as fast as possible to click the other window forward? What speed machine are you testing on? I'm trying to determine if this is something most people are going to see when casually browsing since what I had to do to repro it was not at all casual.

Actually, that comment was directed at Adam Kay. I was trying to clarify whether it was completely fixed on Mac by Hyatt's fixes or just partially dealt with as it is on win32. Anyway, when moving as fast as possible to bring another window forward, I see it nearly 100% of the time on 40% to 50% of all URLs and 0% on the rest. Prior to Hyatt's recent fixes in another bug, I saw it all the time on every URL. This bug forces me to wait on pages to load before doing anything. Otherwise, I end up sending an ALT+F4 to the wrong window or something equally annoying. All the bugs that have a bigger impact on my own browsing have already been fixed. What sort of connection were you testing with? I'm using a 56k dialup, which increases latency. I also frequently have things downloading in the background.

Unfortunately, my earlier comment was a little premature. I too began to see this issue later that day. Once the behavior returned, it happened pretty much constantly. I didn't have to do some obscure ritual to try and get it to happen (I wasn't even trying), and it didn't require the opening of a contextual menu or blazing-fast window switching or even visiting the listed URLs. Just doing some casual browsing and the problem was quite noticeable.

Allright, I'm going to bring this back onto 0.9.1 if people are seeing it that often. I'll keep my eyes open, but please post any more test cases you may come up with.

->0.9.2 per team triage

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

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

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

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

Still seeing this (intermittantly) on 2001052304

when ever I start to load a new page, either from the address bar, or the bookmarks menu, and quickly open a new page, the previous window always steals focus from the newly created window as the page initially loads. I'm currently using build 2001052504, and this activity is constant. I'm using win2k sp2 (and have noticed this on all the win2k boxes I've been using - 3 others).

ARGH! This has totally regressed! Anyone know when it went bad again? I'm tempted to pull this into 0.9.1...

Okay, I'm seeing this whenever the sidebar search results pane decides to make itself visible.

I see my above window focus problem without the sidebar even turned on.

We're having trouble reproducing it on win2k... any other tips, particular pages?

hmm .. it seems to go on me on pretty much any old page. a plain old HTML page with CSS throws it off. It might be a switch that I turn on/off in my profile. I'm going to do some more hunting ..

damn, I just deleted my Mozilla profile, and started from scratch, but the problem persists even with the default profile from the 2001052404 build. I can't seem to make Mozilla stop switching focus during initial page loads.

I have not yet seen any improvement at all on this bug, let alone a regression. As far as I can tell, there is no particular event that that triggers this - just that the window steals focus only the page has finished loading. Seems to happen on every page with or without the sidebar. Using Win2k and running nightly builds about every night.

I'd have to agree with Brett, although, for me, it seems that the focus is being stolen when the page first starts to load, as opposed to when it finishes loading.

It seems to me that it happens every single time mozilla reflows the html. when i browse with multiple windows open I often start a big page going, then instantly alt-tab to another window. When moz grabs the focus, i alt-tab it away instantly. This happens many times until it stops loading.

Yes, I agree... sorry about my last comment - I've been dealing with this for so long I'd forgotten how it was actually working... Josh's idea about page stealing when the html is reflowed seems the most accurate to me - I often browse in a similar manner and that is what I see... but darn (in a good way) - I can't seem to duplicate any of this on my Win2k 2001052404 build - was this fixed?

I just tried out the 2001052606 build under Linux (Redhat 7.1 Gnome) and I see this happening too. So it's definitely not just a Win2k related problem.

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

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

26 dups (including dups of dups etc.). Marking mostfreq.

Okay, I tried this with a slow proxy emulating 56K connection and I still don't see it. Could those of you who see it list your OS, machine speed, RAM, connection speed, and a URL if it happens on some sites in particular?

(Win2k, 500 MHz, 192 MB, 64 kbit/s) Select a newsgroup in newsreader, switch to a browser window before newsgroup loads - newsreader always steals focus back.

Linux (Debian Woody, kernel 2.4.5, XFree 4.0.3, Blackbox window manager), 128 MB RAM, 400 MHz Celeron, 56K dialup. It seems fairly random, but it seems to happen most often on Slashdot (http://www.slashdot.org) and Bugzilla (http://www.bugzilla.org).

[Win2k, 350MHz, 128MB, 49.2Kbps, any site] Open a browser window and type the url to a site or right click and open a link in another window to a new site. Now, before ANYTHING happens on the page (haven't found that difficult to do on my machine) change to a different window. I've really been paying attention recently and I find two times that the new window tends to steal focus: 1. When the progress "twisty" first starts spinning 2. When the progress meter actually (begins to) show a progression. Does this sound accurate to anybody else?

I see this reliably on Win 2000. Build ID: 2001053120

Thi is especially annoying if you follow my browsing style: I open several browser windows at the same time, fire up connections to several pages in the windows i open and ALT-TAB between these windows constantly - while i read a bit of one page, at least three another load other pages/images. They steal focus when they finish loading and that causes total chaos in my browsing experience.

Well, I treid with some previous nightly builds and lost my confidence. I can't reliably reproduce it, but I noticed that it helps if you have a fast machine (so you can switch between windows immediately) and a slow connection (so the page doesn't load before you switch between windows). It appeared to me that the windows get focus twice here: when they're created (eg. "Open link in new window" command) - that's proper behaviour, and then sometimes (not always) when they receive the HTML from the server (but before all images load) - that's the problem here. Anyone may comment on this? I'm speculating a bit here, as I can't reproduce it reliably. Maybe messing with clearing the cache helps a bit to reproduce this?

I've seen it reported with pre-2001052620 builds, but I only managed to reproduce it with 2001052708 and older on Win2K. Is it my problem with repruducing it, or is it a regression that made things worse recently?

OS: Win2k Pro: A800 RAM: 384MB Net: 512k

OK, I reproduced it (unreliably) with 2001-05-26 and 2001-05-24 builds. That's older. Damn, it's just so hard to reproduce it on a fast connection! I can't see this bug unless my provider has some heavy traffic. Any sample sites that are reliably unreliable?

it _might_ be that the focus is stealed by browser as soon as it receives SYN/ACK from the server...

Is anyone able to come up with a box that has a hacker TCP/IP stack and web server so its responses have predefined (delayed), exact timing? Eg. it responses with SYN/ACK exactly 2 seconds after receiving SYN, generates HTTP OK 2 seconds after HTTP request, sends HTTP headers with one second delay after each one, and sends data 2 seconds after the last HTTP header? This could provide a perfect testcase. It's beyond my capabilities, though...

Ok, I played with different nightlies and I am almost sure that this effect isn't as frequent in 2001-05-26 as in 2001-05-31 builds. But I don't have enough time to investigate that further.

I can reproduce this 100% of the time on my system Win98, A700, 256MB, 512k cable, 2001060120 1) Double-click on a bugzilla bug URL in Eudora. Since Mozilla is my HTTP protocol handler, Mozilla is launched 2) Type in another url. http://www.slashdot.org http://www.google.com whatever 3) Press Enter and then *immediately* press Ctrl-N The Mozilla loading the URL you typed in step 2 will always jump on top, even if you are actively using the browser created in step 3.

I'm using build 2001060120 and notice this constantly on a cable connection (not sure of the bandwidth) on my 1.2 GHz Athlon on Win2k SP2. I have a faster connection at work 100Mb fiber, and I still notice this happening. The best way I can reproduce this is to start loading a page via the URL bar, and as soon as you hit enter (to initiate the page load) quickly hit ctrl-n and wait. After a second or two, the browser window that started loading the page will take focus away from the newly created window. I've also noticed this occurence on Redhat 7.1 on an 800 MHz Athlon ..

Okay, I can get this reliably on win2k [500MHz/128MB], and over a fast network, with a variation of the steps noted by wdormann & Stephen Hassard above. 1) clear the cache (to force a network load of the document). 2) have only one browser window open. 3) type http://bugzilla.mozilla.org in the urlbar (but don't hit enter yet). 4) place the mouse over the navigator icon at the bottom left of the browser (which when clicked will get a new window). 5) Now, hit enter and immediately click on the icon 6) New window will come up, but the bugzilla page will push itself to the front a moment later.

Proc: PII 400 Ram: 256MB OS: Win98 Link: 512/64 ADSL Build: 200106104 Url: http://gathering.tweakers.net/search.php?on=topics&search=active Methode: Right-click "open link in new window" then switch back to url. Reproducing : 101%

bug 72651 looks like a dup of this one. (OK, that bug is older, but this bug has more information and votes.)

I don't really think that bug 72651 is a dupe. It's a bug with mozilla restoring the window after a minimize. My mozilla doesn't seem to do this (build 2001060320). Although they may be somewhat related ..

People, can you compare behaviour of the latest nightlies and pre-2001-05-26 builds? It seems to me that this effect has got more apparent since then. This bug is from 2001-04-26, but I have a feeling that with builds around 05-26 it got significantly worse.

I can't say that I've noticed this bug get any worse, but it's always been very bad (for atleast a month). it's probably the most anoying bug that's hanging around in the browser portion of mozilla right now ..

I agree with Aleksander Adamowski. I also feel it were much better.

jrgm's test is the one that I can reproduce easily. That got introduced with hyatt's paint suppression. Paint suppression's timer fires for the old window and steals focus back from the new window. Not sure how to fix it just yet... the bug may be that I'm using a global in window's event dispatch and that needs to be a per-toplevel window variable instead, since paint suppression checks to see if the window is active before focusing. In this case, it claims it is active, but it may be reporting a false positive from the new window. I'm wondering if paint suppression is the cause of all of these (perhaps indirectly).

It's firing for the new window, not the old window. It's trying to set focus to the new window and to do that it has to tear down the old window. I'm assuming the old window teardown is causing a blur.

Did a test and it looks like GetActive is wrong by the time we even get into the unsuppress method.

never mind my comment. i was assuming you meant new doc/old doc as in a single window, but you are referring to the two windows themselves.

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

Seen in every build under Win2K, Win98 since 2001-03 era. Systems: 800MHz Duron, 56K 350MHz PII, DSL (LAN-based) I don't know if the reflow idea works (it just may be), however I do know for sure that a page initiate (whether new window or new link) causes the window to gain focus no matter the status (minimized, hidden, etc) Adding my vote! I wish I could pipe the remainder of my votes into this one.

Quite a good testcase (don't know if it will work for you): 1. go to http://www.planettribes.com/tribes2/images_4.shtml 2. Right-click on a thumbnail and select "Open link in new window" 3. After new window is opened, Instantly switch back to original window (with thumbnail page) 4. Wait until the new window finishes loading - it should steal focus. It works every time for me because these pages load quite slow from my location - it may be too fast for you though.

There's already a directory on Netscape ftp for NN6.1PR1, but this bug will make a huge numbers of complains (it makes the multi-windowed work to a horror), so I think this must be P1 and a NN beta stopper! PS Sorry for the spam.

I have to agree with Eugene. This bug is the only thing that really bugs me on a regular basis. It makes it really difficult to use mozilla for browsing when multiple windows are open. One of the things that I always do with my browser is start a new session, start loading a new page via the URL bar (via ctrl-l) then hit ctrl-n for a new window and blast a new url in, and do this repeatedly about 6-8 times for all of my favourite sites. This bug tends to really mangle this behaviour.

FWIW, IE does this too sometimes, to my incredible annoyance. I frequently end up yelling at the rude windows stuff like, "Hey, i was LOOKING AT THAT!" or "I don't remember asking you a god damn thing! Get the hell out of here!" The ability to scratch this kind of itch is one of the reasons my mouth is watering over Mozilla.

Yes, but in IE this works in slightly annoying fashion while with latest Mozilla nightlies it makes you want to kill someone... (joking of course :-) I think no Netscape version (even alpha) should be released with this bug - that would make for a very bad impression.

Agreed, with much enthusiasm! :-)

I asked PDT too take attention to this one.

Now, calm down people. This bug is P2, has 47 votes and is targeted for 0.9.2. So I think Netscape is doing what they can to fix this as this seems one of the most annoying bugs left. You are always free to help fix this, you know...

Well, now that we've convinced everyone involved that it *does* happen, has anyone figured out what's causing it? Sounds to me like the incremental reflows are resetting a got_focus bit or something. Can't someone set up a debug run to see what values are changing when this happens? What are all the possible reasons that a window can change its own focus? Perhaps looking at every single (shouldn't be too many) of these possibilities should narrow it down... I'd really like to help, honest, but I'm no coder. I've got some programming background so I can offer suggestions; that's about it. :/

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

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

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

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

BTW, I do not see this bug in NN6.1PR1...

You don't see it on PR1? That is odd, there shouldn't be any significant difference.

I defenetly do not see this in PR1. Can anyone confirm?

I can still see this bug in PR1. It seems to be somewhat less pronounced as only high latency sites seem to be noticable. For all others, the browser seems to be fast enough to start loading the page (initial reflow) before I can pop a new window. A good site to test out the focus bug is with http://memes.net as this site is on a cable modem on a slow PC. I can get this to happen on other sites too, though you'll need to find one with a fairly high latency ..

Try starting with -mail, then go to a web page, a click on the mail window, the web page will pop up in front of the mail window.

I also do not see this bug with "-turbo"... Can someone check this out?

I see the focus bug even with the "-turbo" switch on build 2001061504.

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

news.com seems to show this bug nicely on all platforms

Long Slashdot stories should make for good testcases, as they are dynamically generated (*.pl) and thus, I think, not cached. Besides they are slow to load and big. How to reproduce: Open a story. Open a "sub-threaded" comment (one that's not visible on the story page) in a new window and quickly switch focus to the other window (Ctrl-N should work too).

Sites I see it on are Slashdot, The Register, ShackNews (www.shacknews.com) which are all news sites. I got in the habit of opening intresting links in new windows back in the days of 28.8 being REALLY fast. The new window will load slowly, I can read other story snippets while waiting. In these days of high bandwidth, it's not so much an issue of DL speed, but the size and complexity of the pages. Slashdot stories always get a good number of comments, and as the previous post said, are generated by scripts due to individual preferences. Slashdot is an excellent site to see this bug display itself. And although it's very annoying, as Stephan Jaensch said, let's not panic...

New Info: Click a link, and minimize the window. When the first paint starts, the window will pop back up. This is even with all Mozilla windows minimized. I found this interesting, and maybe helpful.

I see chofmann@netscape.com just removed the Status "critical for 0.9.2". What's the point of leaving "needed for 0.9.1"? And what does "PDT+" mean? <rant> Doesn't anyone at Netscape care about fixing what (IMHO) has been the No. 1 usability bug in Mozilla for the past month or so? You can *not* be serious, man! </rant> Sorry about that. I feel better now. Could we at least increase the severity to "major"? Please?

fixing the status whiteboard. Please put your advocacy into keywords or votes. Comments that do not help the bug get fixed are not worth posting. Advocacy and other non-technical comments should be taken to the newsgroups or IRC. (please don't reply to this comment in the bug, use email. thanks).

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

Please update the status whiteboard with eta. It would be cool to have this fix, is there anything I can do to help?

No eta yet

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

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

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

Build: 2001062105 (and many builds before that), Mac OS 9.1, 400 MHz, 64 MB RAM URLs: <http://segfault.org/> (very often), <http://salon.com/> (sometimes) From repeatedly reloading pages where this occurs, it appears that the moment when the first reflow is triggered is pretty constant for the same page. However, sometimes the page has been painted by the time this moment comes, and sometimes it hasn't been (depending on how many other apps are competing for CPU time, how much virtual memory is being used, etc). And where the page hasn't been painted yet, *that's* when the window comes to the front. If you have lots of apps open and you have a non-frontmost Mozilla window open with one of the troublesome URLs, merely switching between the other apps, then switching back to Mozilla (using the application switcher), will often (but not always) cause the window with the troublesome URL to jump to the front. So I don't think it's anything to do with networking activity.

Is this bug going to get fixed for 0.9.2 or not. I read on http://www.mozillazine.org/articles/article1955.html that 'We will be taking only very low risk, very high yield patches for the [0.9.2] branch and we intend to release quickly.' I doubt that this will be a low risk patch, but with apparently no one working on a patch I can't say. IMO it is high-yield, and 68 people agree with me. And before you say anything, I don't know C.

I reduced my bandwidth to near zero to watch each step of this bug, and here's what I found: 1. One window has barber pole load indicator, URL bar 2. The other window has status bar and actually loads the page 3. Both windows have active throbbers 4. Eventually both windows have load indicator and page title 5. The one with URL bar loads page first 6. The other window may or may not load the page, URL bar.. 7. ..if not it will load the page once you enter a different URL and 8. ..you cannot load a different URL in this window.

doh. wrong bug; sorry for spam.

This was a common pr1 complaint.

On a debug build (20010624) I'm seeing this assertion: ###!!! ASSERTION: Attempt to decrement focus controller's suppression when no suppression active! : 'PR_FALSE', file e:\moz_src\mozilla\dom\src\base\nsFocusController.cpp, line 414 It seems to occur whenever this bug would have occurred in the non-ndebug version. I suspect this is only a symptom and not the cause, but I'm attaching a file with 3 different stack traces (Win2k) in the hope that it may help.

The above patch did not seem to fix the problem on win32 (although given my current track record of patches actually working on win32 I should keep my mouth shut). On MacOS, it does seem to fix the problem, but I got my machine in a baaad focus state where windows were inactive/but active. I'll try to veryify that it is this patch, but it is the sort of thing I was affraid of.

I am having a hard time understanding why Mozilla contains code that changes focus *at* *all*. That is, IMHO, the window manager's domain and it is much better at it. (That was a Unix comment, I guess.) The same goes for code that raises windows or even de-iconifies them.

Sorry to be a "me too"er, but Morton, i couldn't agree with you more.

<QA please ignore> Please try to restrict your comments to posts that add technical value to the bug report. Bugs are difficult and time consuming enough to read through without a bunch of non-essential comments. (Did you know that QA has to read every comment in a Resolved Fixed bug report before they can verify it? Please take a moment to read this bug from top to bottom and see how long it takes. Now multiply that out against the 4500 fixed bugs that need verifying. See my point about non-essential comments?) If you would like to discuss this further please find me on IRC or email me. Thanks. </comment which does not help in fixing or verifying this bug>

Asa, I hope you're not refering to Morton's comment. I think he has a VERY important and *related* point. It goes right to the point of why this "bug" is here at all. I'm probably biased - I know I've often wondered why it's so difficult for win32 mozilla to act like any regular hack programmer's creation in such a simple item as focus states - but I think Morton's comment should probably be given more weight in the course of fixing this bug than any other comment I have seen in the comment history. And yes, though I offered no bug-in-action observations nor any this-could-fix-it remedies, this comment was related to getting the "bug" fixed.

<QA please ignore> OK. A short explanation of why we have window-focusing code in Mozilla. And the last time I post in this bug. Please find me in #mozillazine or mail me in person if you want further clarification or wish to respond to my comments. Whenever we bring up a dialog specific to a given window (eg security prompt, save confirmation dialog, etc) we should be making sure that the window in question is visible. Otherwise it's not clear what window the dialog refers to, and this could lead to all sorts of problems, from work being lost to security exploits based on tricking the user into believing that a security alert applies to window A when it applies to window B. This may involve deiconifying a window and/or raising it. For example, confirmation dialogs for saving partially edited emails/editor pages when someone selects File > Quit fall into the category of dialogs that absolutely require the parent window to be unminimized and topmost. Also, with modal dialog windows we have to make sure that the modal window is above its parent at all times and is raised when the parent is raised. Most window managers to not handle this. Futhermore, some Web applications (primarily intranet ones) rely on being able to use window.focus() to raise windows since NS 4.x did so -- see bug 71266 </QA ignoring>

<QA please ignore> it took me 8 minutes i think to read this bug. perhaps we should create a system that lists the relevant portions of a bug so that QA can skip pieces. relevant, most comments on 2001-04-30 through 2001-05-01 14:36 on 2001-05-25 saari concluded that there were issues w/ the sidebar but that disappeared. saari solicited a list of sites/pc configs, which resulted in too many comments, relevant: 2001-06-01 21:26, wdormann 2001-06-02 07:40, John Morrison 2001-06-03 00:28 Aleksander Adamowski 2001-06-02 04:07 thought it might relate to SYN/ACK but i think this turned out to be a red herring bug 72651 is not the same as this bug. saari@netscape.com 2001-06-04 17:13 said jrgm's case pointed to hyatt's paint suppression. hyatt said that a blur event might be the cause. this bug does happen w/ 6.1pr and -turbo more cases: saari@netscape.com 2001-06-18 23:33 through Grey Hodge 2001-06-19 20:26 and Matthew Thomas (mpt) 2001-06-23 16:57 There are no other useful comments for QA to read until after this comment. timkoogleblowsgoats@yahoo.com 2001-06-25 had stack traces based on a focus controller perspective, more code ideas from bryner through saari@netscape.com 2001-06-25 21:55 saying bryner's patch didn't work on win32 but might have worked on macos. bz hopefully explained why we need to deal w/ focus. <list urls> http://www.news.com http://www.tech-report.com http://gcc.gnu.org/lists.html http://www.mozilla.org http://www.slashdot.org http://www.google.com http://bugzilla.mozilla.org http://salon.com/ http://memes.net http://www.shacknews.com http://segfault.org/ http://gathering.tweakers.net/search.php?on=topics&search=active http://www.planettribes.com/tribes2/images_4.shtml The Register</list> There is an additional 2 minutes worth of reading in the older bug 28467 which mentions a few api's that we should use later to correctly notify users that another window wants focus. There is nothing interesting in the bug activity report. </execsum> To some extent we need to manage focus w/in a window, this problem was partially discussed when saari noted the sidebar search panel was a possible culprit. Mozilla implements most things on its own, and asking why we do that is not productive, if people are interested in an application that uses os/toolkit features there are other browsers out there (open: konqueror, closed: ie, icab, ...). [marking top100]

i think i've bitten by this bug with my builds since last week [not completely sure if this would be the correct bug, but jesse pointed me in this direction]. essentially, what i see is similar to llanero@jazzfree.com's 2001-06-15 10:18 comments, when have a mail and browser window open. the annoying thing is that this doesn't seem to happen *all* of the time. :( maybe about 35-50% of the time. but here's my recipe, fwiw... currently using 2001.06.27.04-branch comm bits on linux; rh6.2 w/gnome and sawmill. btw, i have my mouse pointer set to bring focus [activate] but *not* bring forward the window it's over. and to actually bring a window forward, i need to right-click on the window's titlebar. 0. started with ./netscape -P [profile] -mail. while reading mail [eg, bugzilla mail], i open a browser window by clicking a link in the mail message --so now have one mail and one browser window open. 1. my browser window is in front *and* active. i do some editing in the bugzilla report i'm viewing. 2. i hit the Commit button, and *while* the form is *being* processed, move my mouse and right-click on the mail window's titlebar. 3. the mail window goes to the front --briefly-- then the browser window switches back to front: this occurs while the form is still being processed. [side note: fortunately for me the mail window still has focus; it's just in the back, tho'.]

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

I filled bug 88225 for those, who's interested in focus problems.

Guys, the reason you're not able to reproduce this 100% of the time is because you're not quick enough. Mozilla is resetting the focus before you can 'lose' it. You have to immediately switch windows, hell, even slow down your computer with something running, to see it. It's like trying to read a LONG directory listing in DOS without pausing. :)

Yup, anything where paint suppression fires will show this. Meaning you have 1.2 seconds or less to switch windows.

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

Mozilla shouldn't be allowed to steal focus from any other window in the desktop, be it a page load, or a JS focus(), or anything. Focus should be for fields within a page only, there, and only there, the focus should change. Many times I opened mail.yahoo.com, switched to another password field on another page and suddenly saw my password typed on the Yahoo! ID field. It has happened in buzz.builder.com too, which uses the JS focus(), and I saw happening to other people. Windows focus should not change on JS events. Must not change windows when JS events happen. Don't change windows on JS events! But that's me :-) If you run, in windows, regedit.exe, CTRL+F, type "ADFSEFRWGEvTGTGEGEGR" (or anything really, as long as it's not on the registry), then switch to another app, can be Mozilla, then you'll see that the regedit will blink in the taskbar. That's a nice call for focus, it's calling, but it's up to the user when to get it. I think there's an option for this in Windows itself, don't remember where. Marcos.

<QA: You can skip this, it's a comment about comments> Ok, while we all know this is an annoying bug, but that's ALL it is. It's not a discussion about our respective opinions on what should and should not take focus. The fact here is when the page starts to paint, it steals focus, and it shouldn't. We know that, it's being worked on, so let's not keep cluttering this up with opinions. Maybe it's not my place to say this, but I am anyway. Bugzilla is for bug reports, not discussions of opinion, except for a couple bugs which were opened for that purpose. This is NOT one of those bugs. Let's try to restrict our comments to stuff about the bug, eh? </QA> This is 100% reproducable, depsite some folks saying other wise. You just have to be fast. The best thing to do in Win32 is to have 2 windows open, click a link that goes off-site from the current page, then ALT-TAB to another Moz window. I can ALT-TAB back and forth about 6 times in a second, if I REALLY try, so surely someone else can do it too. :)

<QA, ignore> I think Marcos' comment is relevant. Some have suggested that no windows should ever steal focus. BZ pointed out some reasons why windows "have to" steal focus. Marcos showed that on most of those occasions, the windows don't actually have to steal focus. He suggested a better alternative. It's not an opinion, it's an enhancement request and it suggests a possible solution to an annoying problem. </QA>

<QA ignore> In which case he should open up a bug suggesting the enhancement. </QA> On another note, is stealing focus related to bringing apps to the front? part of this bug is that windows are raised as well. does focus = raising in all cases in mozilla? Lastly, I have moz set to ask before accepting cookies. I can middle click on a site and switch back to the original page once the new one appears (still blank), but the cookie warning appears over the first (incorrect) page. If I click on the title bar of the warning, _then_ the new window is brought to the front. Is this related or a different bug?

Reproduction can be accomplished quiet easily... 1. http://www.pricewatch.com/ 2. Search for something. 3. Click on retailers link in the results 4. Click on the website link in the left frame. 5. New window opens up going to retailer's page. 6. Browser that is on pricewatch's page will eventually refresh (the frame where the 'website' link was) causing that window to raise on top of the browser with the retailers page in it. This happens 100% of the time On linux with sawmill/sawfish w/o the WM setting to raise windows on focus.

Has anyone else tried the patch (Bryner's first strike at this bug)? It solves 90% of the problem for me. I no longer have browser windows stealing focus from each other. What still happens is that mailnes steals focus from the browser. I can just about live with that.

I just realized that the title of this bug includes "and other apps". Now, I have yet to experience this part, unless we're referring to other Mozilla apps (Mail, news, Composer, etc.). This is on Win32, BTW. No, unless that patch was rolled into the trunk, I haven't tried it, and if it was, then it doesn't work here.

I believe the "other apps" part actually got fixed before I filed this bug, but I hadn't noticed at the time.

This is quite visable at cnn.com, but clear your CNN cookies first. The popup window there is first in front, then the main window pops to the front. I think there's a seperate bug on this case, but it's probably the same issue as normal windows poping over each other. FWIW, this bug has the most votes, ignoring the PGP Mail support, which I don't see happening any time soon. Changing target based on status whiteboard comments.

<QA IGNORE> Not to smart to set a target milestone that has already past. I has been well known that 0.9.2 would be offical late this week. This bug would need more work then just a day. Also it is not polite to set target milestones for the developers. They have to set their own. They know popular bug..... </QA IGNORE>

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

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

[win2k SP2, 1.1GHz, 160Mb, 56kbps] There is, in my opinion, absolutely no reason for Mozilla to change focus between windows - it's up to the user. Child windows should be precisely that - child windows. So the user always knows which child belongs to which window. In Win32, no app can steal focus from another (that's part of the new rules on window focus created for Win98), and an attempt to do so will cause the icon on the taskbar to blink. I think similar rules are enforced by *nix window managers. However, a window can steal focus from another window belonging to the same app. Steps to resolve this bug: 1: Remove _ALL_ lines of code which change focus between windows - this includes those which set focus to child windows which aren't child windows. 2: Change all child windows to proper child windows, as handled by the window manager. This may seem drastic. But it is correct. The end.

<QA Ignore> No, it is not correct. What do you do then for modal windows that do not sho up on your taskbar/Dock? They will get hidden, theuer will not understand why the application will not respond, and try to close it. This is not up for discussion, debate, conversation, negotiation, or anything else. There is focus code because there needs to be. If you disagree, go download M13 and tell me there's a great improvement over 0.9.2. </QA>

<qa ignore><take on how the bug should be handled>I have to agree with 'Chris Brien'. 1) All child windows are 'modals' on its _own parent_ window, not on root window/desktop. 2) you don't reise a child of window A, over window B. 3) if user is wondering, why App A (in this case Mozilla) is not responding, when he switched to Window A, he _will_ see the child windows on top as Model!I think it is a pretty straightforward usability/gui-design thing. I still don't understand why some people insist on bringing up child windows over _all other windows_. One example, I normally have 20-30 apps open on my Linux workspace - split across 5 virtual desktops. And say if Konqueror has an error (connection timeout) 1) the modal dialog stays on top of Konq window 2) _and_ in the same virtual desktop.which is the way it _should be_, so that it doesn't mess up my work when I am working with other dialogs (gimp per say).I am not sure if there is a better place to discuss this. But this sort of user feedback _is_ relevant to fix/correct this bug. I am so annoyed that some developers(?) trying to hush people about expressing their take on the problem and how it should be handled. I think some are hung up on the notion of mozilla is used to control a nuke plant and if there is an error dialog user should know it straight away. Please.., it is just a browser/mailreader, and <insert what ever it can do today> :-). If there is an error, no big deal, I will see it when I switch to mozilla window.I haven't tried the newer builds. But I don't want to introduce a 'clearly wrong behaviour' and then adding workarounds to it. Sorry if I sound a bit cynical. We are not questioning the excellent work moz-team is putting in. Just putting in our measly 2c to help developers.</qa ignore>

I agree as well. Discussing this issue here prevents the necessity to file bugs for all the other issues, such as the fact that if a connection to a website times out, a window comes up on top of everything else and grabs focus - even if I'm on another virtual desktop. No other application behaves this way. There could be a fix to this bug which _just_ fixes the symptom described here, but then all the other symptoms of the fact that windows take the focus when there's no reason to would remain. I can't see any reason why a window should bring itself to the top. If a browser window encounters an error, the error should stay with the browser window. Then, when the user switches to that window, it has the error right there. The rest of the application should keep running. Is there something which prevents this from happening in any windowing system? Incidentally, what is comparing 0.9.2 to M13 supposed to prove?

That's enough. No more spam. Go on the newsgroups!

news://news.mozilla.org/<3B3FC437.3FF0BC48@rosdorff.dyndns.org>

<QA ignore> I should mention that the reason I am tracking this bug is not because of the dialogs (which IceWM happily neuters -- see "Focus dialog window when initially mapped only if parent frame is focused"), it is because the browser will focus itself on successful load of a page. Across destkops, and interupting my work. Page loading done? Yeah, grab that focus! This is especially bad since I middle click, and alt+tab back to the other window to continue reading (forking off a window for each interesting sub link is what I do to not lose my place). </QA ignore>

The thread started by coehn is at news://news.mozilla.org/netscape.public.mozilla.seamonkey I submit this informationa as coen's link does not work for me, and I use for reading newsgroups (guess it) Mozilla. The thread name is identical with subject of this bug mail messages. <QA_ignore> My negative comment on the UI discussion gaggling will appear in the thread. </QA_ignore>

<qa take note -definition of modal> Grey Hodge - modal windows are modal. They stay above their parent. When you switch to their parent window, the modal window stays on top. You can't interact with the parent without dismissing the child. When a modal child appears for a window which currently does does have focus, the taskbar icon for the parent window (on win98 and above) blinks to get your attention. Modal windows can't get hidden because they are always on top of their parent window (which always has a taskbar icon). I still see NO reason for window focussing code. The JS window.focus() has nothing to do with top-level browser windows. </qa take note> <qa ignore> What has M13 got to do with it? </qa ignore>

<QA Ignore> Look, the M13 comment was saying to compare. It was a milestone pulled out of the air, back when ther ewere still more problems, such as dialogs popping up behind the window, etc. Don't focus on it too hard folks, it was merely an example. The point of this bug is that it pops up the browser window when it starts to paint to the display area. I still think talking about focus code in general is too broad a discussion for this bug, and tha tdiscussions should be in the bug anyway. RFE for removal of focus code, discuss it in a newsgroup, just leave it off the bug reports. That's all. No one is trying to silence anyone.

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

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 gnome desktop with sawfish "hint": go to gnome-control center, select "focus behavior" - deselect "focus on application windows when they first appear" but thats no solution, mostly i want the new window to have focus

Filed bug 88810 which addresses the focus problems in a broader way. Changing summary to reflect this...

I believe I have a great way to test this bug. 1. Create a new browser window (ctrl-N). Put this window behind the first one. 2. highlight an adress, such as: www.salon.com 3. drag that highlighted address over to the other window The second window should start loading up the page without ever recieving focus. If the bug exists, it should take its own focus as the page loads. But really, I havent been able to reproduce the bug lately, with mozilla 0.9.2 on win98. Is it really gone?

On Win2K and WinNT4, .9.2, I still get it just about every time.

Chris, this is PDT+ bug. Tomorrow, on Tuesday, we'll try to build the first RTM candidate. It would be good, if this could be resolved ASAP.

This comment copied from bug 88810: "Uh.. guys? user_pref("mozilla.widget.raise-on-setfocus", false); on prefs.js doesn't do what everyone wants?" (I didn't write that. I don't know if that's an appropriate solution.)

>user_pref("mozilla.widget.raise-on-setfocus", false); Nope, that doesn't seem to make any difference for me (0.9.2). In any case that could only be a workaround - windows should not even grab focus without asking.

The default pref files don't seem to mention mozilla.widget.raise-on-setfocus. The only 'widget' prefs seem to be in the nglayout (!) hierarchy. The only semi-pertinant pref I see might be capability.policy.default.Window.focus -- presuming that this defines the top-level capability from which others inherit, disabling it here might mean that no window in the app can preemptively grab focus (good?). Also be aware that a window raising itself and a window grabbing focus are two orthogonal things, at least outside of the mswindows world, but <opinion qa=ignore> neither should be done except in the most dire circumstance </opinion>.

>user_pref("mozilla.widget.raise-on-setfocus", false); on prefs.js That did exactly the trick I wanted, thank you very much :-) However, I think this should be the default behaviour.

Windows NT Version 4.0 ( Build 1381: Service pack 4) Build ID: 2001070204 I added user_pref("mozilla.widget.raise-on-setfocus", false); to prefs.js, latest version on my machine, found in C:\Program Files\Internet Explorer\Application Data\Mozilla\Users50\nightly\ir8sblcht.slt while Mozilla was not running & then restarted I then tried the test suggested by krappie@hotmail.com above, i.e., dropped www.salon.com into a newly spawned mozilla window ( default blank page in my case ) focus maintained in the window with bugzilla until salon loaded. upon loading it "stole" the focus & popped on top

<qa ignore><assignee ignore>um. who do i have to whack repeatedly to point out the foolishness of the following quote? "windows should not even grab focus without asking." since people are repeating this line I'm going to analyze it here for the millions of people who are cc to this silly bug. A window needs focus, but it needs to ask, so it (a) pops a question dialog below itself .. that way no one will see that it needs focus. someone tries to click on the window, but it can't accept focus because there's a question dialog open. so it pops another question dialog below itself <iterate adnausium>. (b) it pops up a question dialog in front of all windows. This is more interesting because you've just popped up a dialog which takes focus and ... on a related note, there's a more interesting case. I run w/ xmouse and debug builds. when I hit an assert, a dialog appears w/ abort, retry, ignore. if i'm typing in a window, i might type 'the quick brown fox jumped over the l_a_zy dog'. if that assert window comes forward and takes focus before i pass lazy, and i continue typing (the a), i've just _killed_ mozilla -- whoops. If instead mozilla pops the assert below itself, we have a problem, since the app is hung until i handle the assertion - you can't have a window below a hung window and expect things to work. clearly when an assertion occurs focus _can't_ remain in the window, it _must_ go to the assertion dialog (or at least out of the normal app windows), unfortunately for me, they happen while using bugzilla and browsing ...

There seems to be some odd discussion about how to reproduce this bug; its not hard, just go to http://den.bofh.halifax.ns.ca/delay-mozilla.cgi . This is a CGI with a sleep(10) after outputting the CGI header. Minimize the browser... you'll have time... and wait for it to come back on its own. <yet more QA ignorable stuff> I think this is just such a trivial but incredibly annoying behavior, that people are making equivocating statements without really thinking them through. "An application should never EVER take focus" is a foolish statement. Like timeless said, there are times you just HAVE to. (That being said, of course, it'd be nice if the application could just grab focus from ITSELF... my Disksuite management GUI doesn't give a damn that Mozilla has crashed, and I'm sure I wouldn't either, at the time... but, whatever.) I could certainly put up with grabbing focus on important stuff, like wanting a password or an assertion. But most of the annoyance... and the summary of this bug... lies with Mozilla grabbing focus - unminimizing itself and dragging the user off other virtual desktops by force - for a trivial event like a page load. But that problem is what this bug is about, and its being worked on, so I don't see much reason for complaints. The user_pref seems very promising. But, enough of this. Bugzilla isn't the place for editorials. </yet> The user_pref above worked for me using Mozilla on Solaris. But it doesn't seem to make a difference on Win32. Does it disable ALL focus-grabbing, or just on-load?

I've been playing with this now, and it looks like other windows don't steal focus when focus in on the document. But if the focus is on the XUL, they do. I think stealing focus from other apps has been fixed (see someone's earlier comments) Can anyone confirm or deny this behaviour? I was looking at the code for nsFocusManager and I think there may be something in there that treats XUL specially.

<QA ignore> Dear timeless@mac.com Please READ previous comments fully before writing your opinions. A modal window, by definition, will always be focused over its parent dialog. All unbroken Window Managers and Win32 do this properly -- MacOS probably does too. http://www.mfm.com/support/manuals/pcawrg43.158/glossmodalwindow.htm Understand this! A parent window should not be calling setfocus on itself when the modal child dialog will always have a higher Z-order than its parent, and will always receive focus since the parent is blocking on its return. There is no need for it to try ond focus itself! And when people click the parent window, the child dialog will be focused, so you don't have to worry about the child being lower than its parent. That is why modal dialogs were designed! Anyways, aside fram clearing up the misunderstanding of the purpose of a modal dialog (vs. a normal dialog), I can report that the temp workaround JS seems to work under 2001062608 with IceWM on Linux (even with the delay test cgi). I'd prefer this was the default behaviour, and that the focus raising codepaths be deprecated/removed. </QA ignore>

Using Brandon's groovy testcase at http://den.bofh.halifax.ns.ca/delay-mozilla.cgi with build 2001070204 on Win 95 I observerd that with the *first* browser window I opened, i could not reproduce this no matter hwo hard I tried. With the second, and any subsequent browser windows I opened, I could reproduce it every time. And it was not a question of how many browser windows I had open at the time, I just couldnt reproduce it on the one SPECIFIC window that I start with

The javascript solves the problem well enough for me. Focus is not changed, windows are not raised. Good. There is only a small problem remaining. When a cookie confirmation window comes up, it appears over the current, focused window, not the new, correct window. Should mozilla raise windows that need cookie confirmation, or would that still be annoying? Are cookie windows modal? do they need to be for all moz windows, or could they be modal just for the applicable window? In any case, clicking on the title bar of the cookie window brings the proper window to the front. Linux, 2001070209

I think have an elegant solution for this, and other focus bugs. Look at bug 88810 for details.

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

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

Whoa. New aspect to the bug. I was visiting http://www.pricewatch.com today. For those unfamiliar with the site, here's a quick walk through. Select a section to view, then a part so that you get a list of competing vendors. Now, click a vendor's name. You'll notice that the frame at the top of the screen updates with the vendor's info. If you click the WEBSITE link, it'll open their site in a new window. This is where I found this new aspect. After a short period of time, a few minutes, that frame will auto-forward to the Pricewatch info pane via Javascript. When it updates this frame, the whole window will pop to the front, just like other reports here.

I have a fresh tree from cvs this morning and am able to reproduce this bug using John Morrison's comment from 2001-06-03 00:28 and again with this url: http://den.bofh.halifax.ns.ca/delay-mozilla.cgi I applied the 41249 patch and am unable to reproduce the bug in those two cases. I've been browsing with it for awhile now without any strange behavior.

Patch still has issues on mac os. Open bugzilla query page, attempt to click on a text field, no caret. Bugger.

Latest patch (attachment 41249 [details] [diff] [review]) crashes Moz when I click on the "m" icon (bottom left) to open a 2nd browser window. See attached stack trace for Win2k.

On Linux : Patch 41249 works for me. Patch 41530 does not fix this bug; i.e. windows still pop to the front. I had to convert ^Ms so may have made a mistake their or in applying the patches. Both built fine and the source looked correct after the patching. Probably irrelevant details: built using gcc 3.0 -O2 on linux 2.4.6 LinuxFromScratch.

are the patches working good enough that they could go into the trunk at this point to help get some testing?

I have been using patch 41249 on Linux for a few days with few problems. The focus /raise problem is entirely fixed. Occasionally text fields and the browser URL bar lock up (ie I cant get the focus into them). The browser also stops responding to key input (eg ^N). However opening a new window makes the old window work again. The bugzilla query page commonly triggers this. I have only tested patch 41530 for a couple of minutes (ie enough to see that windows do still jump to the front).

I need to test on linux to see what the problem is there, and there are some bugs I see on the trunk (like I can't drag the scrollbar thumb!) that I want to confirm that they're not caused by this/these patches. So no, I'm not comfortable with it yet.

Some people reported that using the patches, the window popping up was fixed but that occasionally the browser window would 'lock up' and you'd be unable to give the focus to text fields or the URL bar. Just wanted to say that I've experienced this quite often with standard Mozilla milestones - certainly with 0.9.1 and 0.9.2 - so it might not be a problem caused by the patches.

Yes there is also bug 82534.

FWIW I have a 90+% reproducible failure for bug 82534 when I run with patch 41249. It does not occur in my (otherwise identical) build with patch 41530. It is: visit the page bugzilla.mozilla.org and then click the link to the query page. The URL bar and text entry fields are then not usable. Interestingly ^N does work if the focus should be in the main page (ie I clicked on page backgorund last). I am not sure whether this should be posted to this bug or 82534.

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

I have built a new build with patch 41760 on an up to date copy of the source. This bug does still occur but it is much more erratic than before: some sites exhibit problems some do not. Moreover running this build after removing my .mozilla directory fixed the bug for a short time. It took a few minutes of browsing and few restarts before it came back. Running an old build and returning to this build seemed to make things worse. Removing the .mozilla directory always made things better for a short time. I can supply more details/run further tests if that is helpful.

Okay, that's just plain weird. Removing/restarting shouldn't affect this at all. What sites were you seeing it happen on, what platform?

I can reproduce it on many sites but none completely reliably (see below). I am running LinuxFromScratch Xfree86 4.0.3 kernel 2.4.6 (on a PIII). Mozilla is built with gcc 3. optimisation -O2. My window manager is FVWM2 with sloppy focus so strictly this is a raising issue rather than a focus issue. My home page (a local file) is just a collection of links. These include (all http:) www.mozilla.org/, www.slashdot.org/, www.mirror.ac.uk/, http://movie-reviews.colossus.net/archives.html, http://galeon.sourceforge.net/news.html. I have observed the bug on all of these sites. My test is to middle-button click on a link and minimise or push to the back the new page. I have keyboard shortcuts to do this (alt+delete and alt+page_down). The pages usually unminimise or raise. If I try to minimise or put to the back using the mouse the bug occurs less frequently. My connection is through a remote squid cache. It is a fast connection (10Mbits/s). For most of the sites I have a high latency since I am in the uk (but not for mirror.ac.uk nor to the cache). I see the same results without the proxy cache (but I have not tested this carefully). The above is with my original .mozilla directory.

Okay, I've found a regression from this patch. On MacOS (this works okay on win32) intial focus in dialogs seems to be broken. I'm seeing this with the mail password dialog. Whee.

I was the one that talked about user_pref("mozilla.widget.raise-on-setfocus", false); in prefs.js I got that from dark's mozilla/linux page That is a partial workaround, in linux all focusing issues with loading of webpages is gone, but it does not fix another case: What about those little modal windows that pop up when a page does not exist, get connection refused , etc? That preference line does not take care of those windows and still they steal focus from each other

Francisco, this problem is addressed by the bug 28586 "use error page, not dialog for inaccessible pages". See also my comment from 2001-07-02 14:53 in bug 88810.

No,no, bug 28586 wont fix all the behaviour made by focusing. It will fix a "page not found" error, but what about when the mail server goes down or when you are downloading a big file and sometimes it timeouts? Maybe this hasn't happened to anyone else but it has happened to me. Sometimes i get a "connection refused" from my mail server and have to retry from 1 to 10 times to get the email downloaded. The point is, the focusing code in windows MUST be removed, especially all those little windows i was telling about. Page loading focus could be fixed by improving the pref.js fix i provided (it fixes 100% focusing page loading problems for me, at least on linux)

Francisco, in any case, this should be discussed in bug 88810 and not here.

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

chris, any update?

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

Well, the only regression I can find from the last patch is that inital focus in dialogs is broken on the mac. It works correctly as soon as you hit tab though... Problem is, I can't seem to get this bug fixed and not break this on Mac, for reasons that I don't quite understand. It appears that the NS_DEACTIVATE is still going to the wrong window, but that surprises me, since part of the part (the nsMacEventHandler.cpp part) deals with this problem specificially. Very annoying.

Yeah, I'm pretty sure the NS_DEACTIVATE is still happening on the wrong window. If I comment out the content blur in the NS_DEACTIVATE handling in ESM, then the intial focus works correctly (it isn't getting blurred by the mis-targeted NS_DEACTIVATE).

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

WooHoo!!!

Okay, I've been beating on this for a couple hours now on Win2K and MacOS 9.x and I'm pretty happy with it so far (read as, I haven't broken it). jag is spinning up a linux build to test with, I'm going to give the embedded products a go. Looking for r/sr if I can still find them at this hour (ha!) Actually, I'd like bryner to review this and he is in bed by now, so I'm thinking this could make an early-ish build tomorrow, but might not get in tonight.

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

Does this patch adress the more general focus issue discussed in bug 88810 as well?

I'm not removing the code that raises windows (we have modal alert dialogs you know) but the patch addresses the problem from another, more flexible approach. The end result is that windows stop stealing focus from each other in many inapporpriate cases.

Saari, are lines 46-48 and 50-52 of the patch supposed to be repeated as such? I don't know much about the patch structure but it seems the net result would be a few too many includes...

saari: Shouldn't the window manager be handling the modal alerts? At least under UNIX, most window managers have configurable even handling of these, ie raise parent center on parent place under cursor, don't raise parent etc If Mozilla is raising stuff by itself, it's overriding the user's preferances that they already set, and all other applications seem to follow.

Yeah, the patch needs some cleanup

patch 42621 works for me. Linux gcc 3.0. Tested with approx 1 hour surfing including running browser buster in a background window for 20 minutes of it.

Brian Ryner, you are aware that your edition of the patch has redundant includes. right?

Any chance this is making it onto the branch tonite? We're pushing to make the Wed build the candidate.

r=bryner on this last patch (since it's basically identical to saari's previous patch)

sr-hyatt, minus the setactive to false that is in the lostfocus part of the code. Remove that block.

r=bryner, again.

Is the checkin still making it before the morning build?

[saari checked it into the branch tonight]

yeah, what blake said :-) trunk coming up

(from lchiang: jrgm - can you verify this fix on the branch? thanks!)

Great work. I've been using build 20010719 for most of the day and it has no more problems with the focus switching to another window when it loads a webpage. For the record i'm running on linux. I can say I'm now using a dream browser. From here on end seems to me just minor bugs/features ... at least with the browser.

I'm still seeing this in Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2+) Gecko/20010719, so maybe I've got the wrong build or somesuch. Can someone direct me to a build with the patch? I'd build it myself, but my entire box got hosed a short while ago, and I haveyet to setup my building environment again...

Running 2001071903 (actually from 2001-07-19-09-trunk dir) on NT4 SP6a, 700 Mhz Athlon, 769kbps DSL. The problem is not totally fixed. I can reproduce it on a couple of sites including http://www.economist.com. If I right click on a link to left click to Open Link In New Window and then click back to the menu bar on the window from which I'm opening the link if I do it fast enough the new Window will grab back focus. It will do that even if it was already partially painted when I clicked back to the original window. The time frame for making it grab focus is probably less than a second or maybe a second. Its a short period. Also, I've had two windows opened, clicked on a link on one window, clicked on the second window's top bar and then shortly thereafter the first window grabbed back focus as to started to paint up its new page. So this doesn't seem fixed to me.

The windows build with this patch is located at ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-07-19-05-0.9.2/ This has not been landed on the trunk to my knowledge (or at least it wasn't landed by saari), so if you are running today's mozilla trunk build, you /should/ see this bug. Otherwise, this is running fine for me on win2k and I'll be verifying shortly.

It was checked in only on the branch. That means only in the builds that have -0.9.2 in the name of the ftp directory and 0.9.2 (not 0.9.2+) in the User-String.

rgparker@west.net : I dont think your first test is any good and I'm sure you had your doubts as well. Once a new window is opened and isnt fully drawn it will steal the focus if you have moved the focus elsewhere, this is quite normal. Now the 2nd seems more likely but I dont think you have the latest build. Currently I'm using 2001071904, however this is a linux box. You may need to check that you have the latest nightly build for your platform from; ftp://ftp.mozilla.org

I hope you're not claiming that "Once a new window is opened and isnt fully drawn it will steal the focus if you have moved the focus elsewhere, this is quite normal" is PROPER behavior, because I sure as hell want my focus to stay where I put it, short of things like modal dialogs informing me my system is going down. I don't want my browser mucking with the focus that I have chosen under any circumstances at all, including obnoxious pop up windows, including dialogs telling me that for whatever reason (like, my DSL has decided to take a 1 minute rest break) some auto reloading page couldn't load and I am getting a cached copy, blah, blah. Leave the focus under user control under all circumstances short of flames spurting from the computer, please. PLEASE. I hope everyone agrees this is the Right Way or at least everyone agrees it ought to be an easily selected option. -joseph

It's a well known fact mozilla is relatively slow compared to the competition. When you right click and open a new window mozilla is the slowest of them all to create that new window. It's also normal that any new window that's created jump to the front of the screen aka take the focus. If he's creating a new window and before it is created moves to another when the window is created it will be on top ie. it will take the focus away. It is the slow rendering of Mozilla that makes this obvious compared to other programs. However the only program I've seen that doesnt retake the focus is Office 2000. New windows in office can load in the background. Most other programs do not do that. When a user launches a program one assumes he wanted to use it when he lauched it. If the UI takes long to appear when it does appear it will pop up because yo started that window to use it at that point in time, or at least thats the basic assumption. If your pc is slow enough you can achieve the same result with IE 3 + as it loads new windows. So unless you misunderstood, what I said is quite normal.

Okay, the build here: ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-07-19-05-0.9.2/ does appear to fix the problem. Hurrah! Congrats on a job well done and thank you.

That was one of the most annoying features of IE3, and the download windows in IE4, I believe. It was removed in IE5, right? What's that tell you. > When a user launches a program one assumes he wanted to use it when he > lauched it. No. When a user launches a program, one can only assume he wanted to LAUNCH it. I routinely read through an article, middle clicking all the links I want to follow, to open them in a new window. As soon as the new window appears (but long before the page has started to render) I alt-tab back to the first window, and continue reading the article. That way I don't have to run backwards for links to follow when I'm done. It's quite aggrivating when I alt-tab away, and 4 or 5 seconds later Mozilla switches windows back for me. ALSO, saari, or anyone authoritative, I never got a responce to my issues in the 2001-07-17 13:51 comment, regarding UNIX window managers commonly allowing the user to set preferances regarding modal alerts and their parent window (whether to raise the parent and the dialog, just show the dialog, or place the dialog on top of the parent, how ever deep the parent may be.) Mozilla shouldn't be overriding that preferance, at least on UNIX, where it's possible for the user to configure globally for all (well behaved) applications.

Got that branch build, been beatingon it at my worst offending sites (Slashdot, The Register, Shacknews) and looks great. Aside from CNN.com's bitchy popup ads popping up over everything (but that happens to me in all browsers, so that's not a bug) I'm very happy now. It gets the Burnt Electron of the Week award. This bug's toast. Don't see any regressions or anything either, as noted by CNN's nasty popup behavior, amongst other things.

Okay, I am taking my life into my own hands here, but ... for most intents and purposes, on mac(os9.1) / win32(win2k) / linux(gnome+enlightenment), with the 2001-07-19-nn-0.9.2 _branch_ builds, this buggeth is fixeth. 1) I have been through many of the scenarios noted, including: 2) opening a new browser window and moving back to the first window quickly (by alt-tabbing, by clicking), 3) I have submitted to bugzilla and moved to another window particularly mail, 4) I have launched mailnews/aim/composer and moved back to the browser window, 5) I have done bzbarsky's linux bugzilla submission (window in background; hit submit, does not raise), 6) my (borrowed) recipe for rapidly hit enter for a URL and click the Navigator icon to get a new window. 7) <input type=text> gets focus in a background window -- does not raise on any platform (but window.focus() appropriately does). 8) a bunch of ad hoc bashing on three platforms. I'm sure I've missed something. I'm sure it will be noticed :-) There are two narrow conditions, one on Mac and the other on Windows that I could trigger, but I will be filing these as separate bugs [mention Linux on the win32 bug, or win32 on the Mac bug and Ye shall be shunned]. a) Mac: cmd-click to get new window, click in first window, second window keeps forcing to front (although the UI thread is pretty busy at that time, and it just not be getting my click event). b) win2k: do Ctrl-N to get a new window, and /at just the 'right' moment/ ALT-TAB back to the first window and the new window will force This is still due to land on the trunk. (Mention the trunk before the fix lands and Ye shall be double-shunned).

What about those little modal windows that say "connection refused" Those still take away the focus... Will that be fixed in another bug? For example i get those in my pop3 email lots of times, and we cant substitute that window for a "page not displayed" like in IE because we are talking about mail

File new bugs for the remaining issues. As far as I'm concerned, this specific issue is fixed.

Chad (aegis): It will be really fixed when it's checked into the trunk :-( Francisco (fileon): you're talking about bug 28586 (mentionad several times on this page)

patch just landed on the trunk

Regarding "Additional Comments From bugs@burntelectrons.com" "(but that happens to me in all browsers, so that's not a bug) " Is not an excuse for negative behaviour. Mozilla is often the only browser which doesn't screw the pooche raw on CSS, with the possible exception of IE 5 for the Mac, because it's the only one which supports the vast majority of CSS1 and CSS2 and works as the standard says it should.

Dylan G, I believe this issue has been discussed in bug 88810. Something to do with Javascript specs or something, so this behaviour is actually compliant with the standards :/. Perhaps it would be more productive to file a feature enhancement petitioning for a permissions scheme for popups similar to the ones for cookies and images. And to everyone, please stay on topic, this is not a newsgroup.

> Perhaps it would be more productive to file a feature enhancement petitioning > for a permissions scheme for popups similar to the ones for cookies and images. See bug 29346 (allegedly fixed), bug 33448, bug 64737 and bug 75371.

Bug 91632 was filed in order of connection refused modal windows taking focus in mail, which WONT be fixed in bug 28586

marking fixed.

Well, in the 7/20 trunk builds, I can't reproduce the win32 and the mac behaviours that I noted yesterday. And otherwise things seem good to me, in general. Marking verified for the trunk. If this flat-out regresses in the future, I suggest that whoever notices it file a new bug describing specifically what they are seeing. This bug has become somewhat unwieldy, although it was a particularly annoying bug. If there are subtle variations of this type of window z-order/focus behaviour, please file new bugs specifically for those problems, particularly where those behaviours are platform specific. Same thing for RFE's about policy changes. Thanks all (213 on the CC list at last count! I actually get bugmail in my inbox before this bug has finished being processed by bugzilla :-]

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

I stil see the issue in 50% cases. Build 2001072208, very slow NT4 (64M mem.)

it's fixed for the navigator part, but not for the mail/news part. e.g. if you choose a secure connection for a mail server the certificate validation still pops up, even if I was using a navigator window.

I've got a 100% repro testcase. 1. Open http://www.tucows.ibs.ee/business/organize95.html 2. CTRL-Click on any listed link 3. Quickly CTRL-TAB to previous window The second window steals focus. Win 98SE, moz 2001072303 (1st detected with 20010720xx) TRUNK

James Lariviere, how should the test work?

Jumped the gun on me... damn mid-air collision! Glad I'm not the only one who still sees this problem. Open the testcase. Resize the testcase browser window so it is not maximized. Click on each of the four links. Before you get to the last link mozilla switches to a different window (ESPN always seems to steal the window focus the most consistant). Trying to open 10 windows like this gets pretty annoying because you have to fight mozilla to stay on your original testcase window and not switch to the newer windows because it finishes loading or whatever.

Sadly enough, it's 100% WFM on my Win98SE boxes. I spent 10 minutes now trying to reproduce it, even going so far as to open a huge Slashdot story on another box with a 33.6 modem. Works fine.

Grey Hodge, which test WFM for you?

Using Windows 98, Nightly build 2001072208. The JavaScript code self.focus() appears 3 times on the ESPN site mentioned above, like this in the <head> tag: // NEEDED FOR FRAME REFRESH self.focus(); and on <body onLoad="self.focus();" onUnload="self.focus();"> Grey Hodge, really sadly is that I was able to reproduce the bug as Eugene Savitsky mentioned, at 2001-07-23 10:39, except that I only did this with ALT+ESC, because ALT+TAB is slower by (Windows) design (window will only change after you release the TAB key, while it will immediatelly change when pressing ESC), and you have to do this very quickly (IMO because the window wasn't drawn yet. But that's just a wild guess! Don't quote me). I think I was able to reproduce it only once using ALT+TAB though, between many tries. ALT+ESC was easier, you have to be fast enough, though. Real fast I mean. IMO, it's moderately hard to happen in a real world situation, unless the user wants to open many links from one page, or is really experienced (you know, the more you do something, the more you do it faster. Take musical practice as an example). IMHO, worth reopening the bug. *sigh* Marcos.

Grey Hodge, this bug happen when the page starts loading, so opening a huge Slashdot story won't make a difference, unless the server takes sometime, like 1 or 2 seconds, before it sends any content to the browser (eg http headers). But I maybe wrong. If so, someone please correct me. Now, an update. I'm 99% sure that this specific bug is fixed, because no more "Windows steal focus from each other when page starts loading". What's left is JS .focus(), and the times when you ALT+TAB or ALT+ESC so fast that the window wasn't even drawn, so it'll steal focus. Which are both bad, but different bugs. BTW, forgot to mention, I'm using a PIII 733, 128RAM Marcos.

Ok, I see it _now_ using Brandon Hume's CGI, but that's the only reproduction I'm seeing. Being on DSL makes sites come up fast... Rather than searching for that, here's the URL: http://den.bofh.halifax.ns.ca/delay-mozilla.cgi

Restoring mostfreq. This bug has 48! It makes it the most duped bug alive. (Generally, I do not believe that erasing keywords on fixed bugs is a good idea; they tend to be reopened).

I can repro it on each site. But I think this is the _new_ window problem: When I just press CTRL-N and the new window just appears it raises the focus back, but when I will wait a bit longer that all is OK. So I think there is a the second issue. I suggest to close yhis bug as fixed (since I reopened it) and fill a new bug for the fast CTRL-TAB.

New bug. Good.