m13 wouldn't start w/o a crash. totally unstable, so i downloaded a nightly build of m14 around feb 23, maybe feb 22. installation is flawless and much more usable than m13 release. however, when the browser and messenger window open they open up BEHIND existing windows. they are not minimized, they just don't grab the focus. so, you need to find them on the taskbar and click to get them to the front. this has never happened in any previous release. i've been with this since m9 or m10. now, that said, win nt has problems with focus and this is not the first alpha or beta code i've had that did this. no production code ever has, however.

On Windows 2000 it starts minimized completely. Also, the splash screen never shows. I pulled today's source from FTP and built a debug version and the splash displays fine and the window opens normally. When I build an optimized build, the application always opens minimized and does not show the splash on start up.

SPAM: adding self to cc: list

Changing summary field to more fitting description. Verifying still is a problem with M14 final and subsequent builds from CVS as well.

I also see this on W95 M14 - Mozilla continually opens at the back of the window stack, not the front (although I am getting the splash screen). Gerv

is anyone seeing this on the latest m15 builds? try deleting moz (including the moz files in the /windows/system/ directory and reinstalling.

Yes. This is the one bug that is absolutely 100% consistent. I regularly pull a freshh CVS source and compile (last was yesterday). I always delete mozregistry.dat, etc. Still see this.

Sending this to XPApps for a look.

A little hard telling what this bug is about. The minimize problem was fixed, or at least should be fixed. Is this bug about the focus problem or no splash screen?

It depends on what is causing it. I can tell you that if I delete mozregistry.dat, then even the profile wizard starts minimized. In no cases is the splash screen displayed at all. The splash screen is displayed when running a debug version, but the app still starts minimized.

shrir, can you help on this

Similar to bug 28467 ?

I tried today's commercial build on Win2k Here are my observations: 1. Splash screen does appear after installation and before the browser launch. 2. Browser launches with a big window and is not minimized initially. I tried this thrice with the mozregistry.dat removed but the browser launches fine. 3. Windows z-order problem (browser and messenger going behind other windows) is not reproducible and was fixed in bug 28467

I don't know what to say unless there is something that could be system specific causing this. Is there anything else I should get rid of besides mozregistry.dat and mozver.dat that could have any bearing on this? I am also wiping out Users50 and the entire "bin" directory when trying this. I have also tried different chromes which exhibit the same behavior. I have noticed that if I launch Mozilla with "mozilla -console" I get the splash screen, and the application is *not* minimized. The main Mozilla window does open behind the console when I do this though.

For once, I agree with Jerry that starting the browser on WIN2K from the console with the command "netscp6" shows the splash screen behind the console (gets hidden) and the browser window also appears behind the console after it launches. This happens only on Win2k. WinNT is ok. Ideally the splash screen and the browser window should appear on top of all open windows. Am updating Summary to reflect this.

But when you launch it without "-console" it doesn't start minimized for you?

Nope...the browser just launches fine even with the "-console" option. Is it 100 % reproducible for you ?

I meant...with or without the '-console' option, it works fine for me...

It is 100% reliable. I don't recall when it started happenning, but I think it was around the time that the console disappeared. It has occured with every single downloaded build, or bits I have built myself, for at least the last month or more. OS & Video Details: Windows 2000 Advanced Server 5.00.2195 Creative Labs RivaTNT2 Ultra 1024x768 32bpp

Just adding a note to let people know that I still see this as of the 200040208 build.

jerrybaker - are you still seenig this with the new m16 builds?

I am seeing it in 2000041108 still. Is that an M16 build?

Another periodic checkin to say that it is still happening with 2000050820.

reporter - please try by deleting all mozilla files. BTW, are you using installer or the .zip files?

I use the ZIP files. I also delete mozregistry.dat and my users50 directory with each new nightly. I then proceed to wipe out the entire directory in which Mozilla was installed.

shrir - are you also still seeing some of this behaviour?

Reassigning as per Don

In frustration at this stupid bug, I tried something new as well. I tried creating a shortcut to Mozilla.exe (instead of double-clicking it directly) and making the properties of the shortcut say to open it in a mximized window. No luck...it still launches minimized to the taskbar.

Move to M21 target milestone.

Just making my regular checkup to let the developers know that this is still happening with 2000060820.

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

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

Asa/Doron: using the same system as before you can come see this whenever... It seems that i'm not bugged by this because i usually have some desktop visible. So for some reason the behavior is different if the desktop is not visible at all.

Minus. No fix. No biscuit.

This has been around a long time... so I don't see how this could be blocking usage (and not have been screamed about). Marking dogfood-minus

anyone still seeing this at all?

Yes. Everyday. I wasn't as clear before. All you need to do to see this is maximize Windows Explorer and run Mozilla by double-clicking mozilla.exe.

failing to see this win09 2000101904, adding qawanted

This is extremely easy to reproduce. All you have to do is maximize Windows Explorer and browse to Mozilla.exe and double-click it.

Bug 45805 looks like a duplicate of this bug

nav triage team: Still see this using 12-14 build on win2k by maximizing windows explorer, but we're not going to hold up beta1 for this. Marking nsbeta1-

Marking nsbeta1- bugs as future to get off the radar

I feel strongly that this bug should be fixed for version 1.0. I tried adding the mozilla1.0 keyword to indicate this, but apparently I need special security clearance to be able to do this. Yes, it is a minor bug, but it is highly visible. Every time you start Mozilla on Windows 2000, the browser window appears at the front of the z-order, but it is not the active window. You have to click on it or on its taskbar button before you can start typing the URL. (Build 2001051804)

adding Milestone nomination. pchen, this is a serious usability regression for both Mozilla and Netscape. It doesn't seem reasonable to me that because it missed beta that it belongs in Future. Current status of this bug. Launching Mozilla on a win2K machine does not give browser window fucus until the user clicks on the window.

I'm kind of amazed not to see any discussion of the low-level issues causing Mozilla's 'shyness' at the code-level in this bug. Is there no one cc'ed on this bug who can summarize some understanding of what's going on? We (ActiveState) want to help solve this issue, but I'm sure that someone has done the preliminary digging on this issue in the years it's been around... I'm also amazed that no one from netscape is cc'ed. This simply must be a usability issue for NS's products as well...

qa reassign: XP apps default QA

nav triage: this would be a great bug for someone to take and fix. law is overloaded on m0.9.2 with a bunch of other critical things. anyone wanting to take this, please do and thanks! moving to mozilla1.0 as the earliest time that law can look at this.

nav triage team: This is REAL annoying, but it's not dogfood. Marking dogfood-

Has anyone tried this patch? For Komodo I am getting mixed reports about its effectiveness.

*sigh* - this patch appears to work much better with debug builds than release builds. I'll dig some more...

That may be because the console windows for debug vs. release builds are fundamentally different. In release builds, you have to say "-console" and in that case, the console is "dynamic" (created using some cryptic and obscure Win32 APIs that create a window that likely has some funky state). I think the dynamic console window has the side effect of bringing the Mozilla application to the foreground, pulling the Mozilla nav/mail windows to the foreground along with it. On Win2k (and later Win98 releases?), ::SetForegroundWindow won't work unless the application is in the foreground. Does it do the same thing if you suppress the splash screen? The splash screen is on a separate thread and that might be complicating things further.

> On Win2k (and later Win98 releases?), ::SetForegroundWindow won't > work unless the application is in the foreground. According to the MS docs, it should also work if the process that created the new process is in the foreground. It seems to me that this should always be the case - either Explorer or cmd.exe are in the foreground when starting. I get the same results with and without a splash screen. Your thoughts on the console appear to be right on the money - starting a release build with "-console" does indeed work. However, without this patch, the "-console" option still doesn't work quite correctly - the console itself remains activated. *sigh*

Patch added to bug 65974 also corrects this.

Just checked in fix to bug 65974 - so this should be fixed. Leaving to bug owner to verify and mark as such.

This is FIXED. Tested with 2001062104 mozilla win32 build on win2K. I believe that law is on vacation so I'm taking the liberty of Resolving it. If anyone disagrees please reopen. Thanks.

Mass removing self from CC list.

Now I feel sumb because I have to add back. Sorry for the spam.