Closed Bug 77675 Opened 23 years ago Closed 23 years ago

Windows steal focus from each other when page starts loading

Categories

(SeaMonkey :: General, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: gmiller, Assigned: saari)

References

()

Details

(Whiteboard: PDT+; fixed on branch; verified on branch)

Attachments

(15 files)

8.49 KB, text/plain
Details
9.41 KB, patch
Details | Diff | Splinter Review
11.06 KB, patch
Details | Diff | Splinter Review
5.78 KB, text/plain
Details
10.62 KB, patch
Details | Diff | Splinter Review
11.06 KB, patch
Details | Diff | Splinter Review
11.26 KB, patch
Details | Diff | Splinter Review
3.79 KB, patch
Details | Diff | Splinter Review
13.94 KB, patch
Details | Diff | Splinter Review
3.17 KB, patch
Details | Diff | Splinter Review
14.16 KB, patch
Details | Diff | Splinter Review
11.56 KB, patch
Details | Diff | Splinter Review
13.59 KB, patch
Details | Diff | Splinter Review
13.17 KB, patch
Details | Diff | Splinter Review
515 bytes, text/html
Details
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Assignee: asa → saari
OS: Windows NT → All
Hardware: PC → All
QA Contact: doronr → jrgm
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.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
Keywords: 4xp
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?
OS: All → Linux
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.
OS: Linux → All
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.
Target Milestone: --- → mozilla0.9.3
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.
Target Milestone: mozilla0.9.3 → mozilla0.9.1
Blocks: 75643
Priority: -- → P2
Whiteboard: needed for 0.9.1/Mojo beta
->0.9.2 per team triage
Target Milestone: mozilla0.9.1 → mozilla0.9.2
*** 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.
Keywords: 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).
Whiteboard: needed for 0.9.1/Mojo beta → needed for 0.9.1/Mojo beta critical for 0.9.2
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.
Whiteboard: needed for 0.9.1/Mojo beta critical for 0.9.2 → needed for 0.9.1 , PDT+
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).
Whiteboard: needed for 0.9.1 , PDT+ → needed for 0.9.2 , PDT+
*** 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?
Whiteboard: needed for 0.9.2 , PDT+ → needed for 0.9.2 , PDT+; need eta
No eta yet
Whiteboard: needed for 0.9.2 , PDT+; need eta → needed for 0.9.2 , PDT+; 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]
Status: REOPENED → NEW
Keywords: top100
Keywords: nsBranch
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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.
Target Milestone: mozilla0.9.3 → mozilla0.9.2
<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>
Target Milestone: mozilla0.9.2 → mozilla0.9.3
*** 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!
<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...
Depends on: 88810
Summary: Windows steal focus from each other and other apps → Windows steal focus from each other when page starts loading
No longer depends on: 88810
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?
Whiteboard: needed for 0.9.2 , PDT+; no eta yet → needed for 0.9.2 , PDT+; 7/9 second round of patches are being tested
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.
Blocks: 88810
*** 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.
Whiteboard: needed for 0.9.2 , PDT+; 7/9 second round of patches are being tested → PDT+; ETA: read my last comment in the bug
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!!!
Whiteboard: PDT+; ETA: read my last comment in the bug → PDT+; new patch!!
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
Attached patch one more time...Splinter Review
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]
Whiteboard: PDT+; new patch!! → PDT+; fixed on branch
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).
Keywords: vtrunk
Whiteboard: PDT+; fixed on branch → PDT+; fixed on branch; verified on branch
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.
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → 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 :-]
Status: RESOLVED → VERIFIED
*** 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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Attached file testcase
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).
Keywords: mostfreq
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
I thing that this new comments doesn't really apply to the original purpose of
this bug. I can try to reproduce that stuff about quickly opening a new windows
and then alt-tabbing back, and sure, the new window steal focus, but: 
1- It is stealed when the window is created, not related to the download.
2- AFAIK, this is a MS windows "feature"

So this should be treated as a new bug.
Anyway, for all of you who want to open a lot of links while remaining on the
same window: You should focus your efforts on bug 56690 instead. Just think
about it a moment, instead of Ctrl+Click, and Alt+Tab, just Ctrl+Shift+Click.
Keywords: mostfreq
Negative, it's not window creation. Open this link in a new window:
http://www.eeggs.com/tree/153.html
Now it is written to pause for a few seconds, so when you see the new window pop
up, switch back to this window. Wait. The other pops up in front of this one.

Agreed on new bug though.
This bug has still 48 dups on http://www.mozilla.org/quality/most-frequent-bugs/
until it is fxed/verified with or without the mostfreq keyword. Deleting
keywords before that (and prabably even after verifying is a bad practice).
Especially mostfreq which very helpful for finding new dups (yes, they will crop
out for some time after fixing a bug).

Restoring mostfreq 2nd time today :-(
Keywords: mostfreq
For the alt-tab for new window case, there is a definite timing window needed to
reproduce it. I personally haven't been fast enough to do it, but others have
(and then have not again later).

I'm not going to consider that case a critical issue due to the
timing/difficulty of reproduction, but feel free to file another bug. If there
are other very reproducable cases, please file new bugs. Thanks.
verifying again. File other bugs for specific examples.
Status: RESOLVED → VERIFIED
*** Bug 95221 has been marked as a duplicate of this bug. ***
Recent builds have this bug again. Reproduced on Mac and Linux.

Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Confirmed on win32.
The problem is not as big as before, but it's there.
File a new bug.  There are still many, many focus issues, but this particular 
one is fixed.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Verifying, as nothing really changed since the bug was FIXED/VERIFIED..
Status: RESOLVED → VERIFIED
Filed new bug 97542
Ahem, time to put your 75 votes to use on something important. This problem or
its twin is back as described in bug 97067, awaiting your (voting) action, so
that maybe this does not slip into 0.9.4...
*** Bug 96583 has been marked as a duplicate of this bug. ***
After 97067 was closed too, I have filled NEW bug 105225 describing this problem.
This CLOSED bug still has 57 votes!
Please all, move your votes from this to bug 105225.

Product: Browser → Seamonkey
*** Bug 239900 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.