45805 - Splash Screen fails to get focus and falls to background

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[Thomas Swan]

When Mozilla starts the splash is pushed to the background (behind existing 
windows) instead of the foreground (in front of existing windows.)

OS: Windows 2000
Mozilla Builds: (All Win32; nightly and milestone)

This has occured for the last few milestones and all nightly builds for an 
extremely long time.... (I vaguely recall when it did come up to the foreground)

This is cosmetic, but it would be nice to have this work correctly.

Comment 1

[Stephen Walker]

marking worksforme. works on w2k, nt, 98, & mac

Comment 2

[Stephen Walker]

reopening

Comment 3

[Stephen Walker]

confirming. splash screen shows up in the foreground if you use -console but 
goes to the background if you just run mozilla.exe with no options

Comment 4

[Stephen Walker]

reassigning to xp apps default owner

Comment 5

[Stephen Walker]

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

Comment 6

[Steve Chapel]

Also, the Select User Profile and TMHC Proxy dialog windows do not get the
focus. This is especially frustrating when I don't get the Select User Profile
dialog, but I do get the TMHC Proxy dialog. If I have other windows open, I have
to guess when this dialog appears and click on Mozilla in the Toolbar in order
to enter my username & password.

Comment 7

[Steve Chapel]

Looks like a duplicate of Bug 29172

Comment 8

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 9

[Steve Chapel]

I just reinstalled build 2000120720 from scratch (including deleting my user
profile), and the behavior changed. The Splash Screen and Proxy dialog boxes now
come to the front, but the Proxy dialog box still does not get the focus.

The behavior of the console window described in Bug 29172 is still the same: the
console window still comes up in front of the other Mozilla windows.

Comment 10

[Paul Chen]

nav triage team:

So we minused 29172, but we gotta look at some of these window ordering issues.
Marking nsbeta1, mozilla0.9.1, reassigning to law, adding danm to cc

Comment 11

[Eric Hedström]

Using Win2k, I usually start "mozilla -mail", and it comes up with a dialog to
enter my mail password. However, neither the main window nor the dialog has
focus when they arrive, and often they are behind other windows. The browser
doesn't get focus either if I start it by running "mozilla".

This has been true as long as I've been using mozilla builds (several months),
but I did notice when I used NS6.0/6.01 that it *does* grab focus when it starts.

Feel free to paste this into bug 29172 if it's more appropriate there.

Comment 12

[Paul Chen]

nav triage team:

This is annoying, marking nsbeta1+

Comment 13

[Viswanath Ramachandran]

as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 

Comment 14

[Bill Law]

This WFM with a recent build on Win98.

I can believe there might be problems if you're using "-console" or maybe even 
running a debug build (in which case Mozilla is a console application).

Are people still seeing problems here?

Comment 15

[Eric Hedström]

My entire comment from 4/5 is still true. Mozilla never gets the focus when it
starts, and it usually starts behind other windows. I get win32-installer builds
a few times a week.

Sounds win2000-specific.

Comment 16

[Bill Law]

Eric, are you starting from a cmd-line prompt or by double-clicking a program
icon or shortcut?  Do you see the same thing with "mozilla" as with "mozilla -mail"?

I'll try on Win2k next week and see if it behaves differently there.

Comment 17

[Eric Hedström]

The same thing happens when the installer launches it at the end of the install,
and when I run mozilla from a command line, windows explorer, the desktop
shortcut, or my "mozilla -mail" quicklaunch bar shortcut, on a laptop with win2k
professional and a desktop with win2k server (and different video drivers etc.,
of course).

Starting from a command line or windows explorer, the command line or windows
explorer window keeps focus and stays on top of the splash screen and mozilla
window. Starting from the desktop shortcuts, the mozilla window still doesn't
get focus but it seems random where it falls in the z-order.

Comment 18

[Eric Hedström]

Just for a sanity check I fired up the old win95 laptop, and this wfm just fine
there (win32-installer 2001-0602-22-trunk, starting from installer or desktop
icon). So it is specific to win00. Well, I haven't tried it on NT4, but haven't
seen any reports of it there either.

Comment 19

[Thomas Swan]

When I filed this one... I remembered checking on Windows 98 and Windows 95 and
it worked on them.  I believe that's why I marked it Windows 2000 only :-)  I'm
glad someone is double checking... 

Comment 20

[Todd Pringle]

nav triage:  nice to have, not an rtm stopper.  moving out to 0.9.3.

Comment 21

[Mark Hammond [:markh] [:mhammond]]

Attachment: Patch that appears to ensure the slash screen is always foreground.

Comment 22

[Alexandru Savulov]

just a hint guys:

MS changed the way SetForegroundWindows works on Win 2000. Take a look at 
http://msdn.microsoft.com/library/psdk/winui/windows_1eev.htm and you'll know 
what I'm talking about. I had this trouble before as I worked on some GUI issues 
for the previous comapany I worked for. Also take a look at 
AllowSetForegroundWindow. This is a win 2000 issue and it needs a little bit of 
trick-work to get arround it.

I observed that also the main window of mozilla has this problems. Start mozilla 
from explorer dblclicking on mozilla.exe

Comment 23

[Mark Hammond [:markh] [:mhammond]]

SetForgroundWindow certainly has changed in Win2k - however, in most cases we 
meet the documented requirements - the foreground process will generally have 
started mozilla (be that explorer or a command prompt).

See bug 29172 for a similar patch that does fix the problem when started from 
explorer.  Does for me anyway :)

Comment 24

[Mark Hammond [:markh] [:mhammond]]

Patch added to bug 65974 also corrects this.

Comment 25

[Mark Hammond [:markh] [:mhammond]]

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

Comment 26

[Thomas Swan]

Waiting for a nightly to come out... Then will check... ;)

Comment 27

[Viswanath Ramachandran]

marking fixed in line with mark hammonds comments. 

Comment 28

[Thomas Swan]

Seems to do the trick for me... :)  Thanks all!