26581 - After splash screen closes, next window (ProfileManager)is hidden if other windows open on desktop

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Grace Bush]

Steps to reproduce:
1. Install, launch (first launch crashes - bug 26574)-do second launch
2. Open other applications on desktop

Actual results: ProfileManager window is hidden behind other apps.

Expected results: Profile Manager comes to top of all apps for use.

build 2000020410

Comment 1

[Bill Law]

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

Comment 2

[Bill Law]

Marking beta1.  This is really annoying.  There might already be a bug on this 
and the problem lies deep inside widget/window code but I'll dig into it since I 
 at least exposed the problem, if not caused it.

Comment 3

[leger]

Putting on PDT+ radar for beta1.

Comment 4

[Bill Law]

Could use help on this from either danm or maybe the author of nsWindow::Show 
(Kevin McCluskey?).

Comment 5

[Charles Manske]

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

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 7

[Bill Law]

This isn't fixed yet.

I can find no SetForegroundWindow calls anywhere in our code base.  This means 
that our windows come to the foreground only by "accident" (by the user bringing 
them to the foreground or by virtue of being launched from the foreground).  
When we had a console (and no splash screen), I think the first window 
"inherited" foregroundhood from the console.  Now, the splash screen (which has 
style DS_FOREGROUND to force it to foreground) intercepts that.

I tried inserting a SetForegroundWindow call so that the first top-level window 
goes into the foreground.  That worked, except it then caused a crash when you 
clicked the "Start Mozilla..." button on the Profile Manager dialog.  The crash 
seemed to be due to some NS_DEACTIVATE code getting triggered and producing some 
bogus state.  I noticed that this NS_DEACTIVATE code never seems to get called 
without the explicit call to SetForegroundWindow which leads me to believe that 
that code may not be fully functional and/or tested.

Anyway, I don't have a fix.  I'm going to try a few other things and if I find 
some way around this, I'll see about checking it in later.

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 9

[Bill Law]

My estimate is that this will take 1 day after I can get to it.  This will be 
Monday, Feb 21 if all goes according to plan.

Comment 10

[Christine Begle]

updating qa contact

Comment 11

[Daniel Bratell]

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

Comment 12

[Bill Law]

I'm pushing this off till Feb28 in the hope that somebody else will get stuck 
with it.  It's really a xptoolkit problem, anyway (hint, hint).

Comment 13

[John Bandhauer]

Attachment: A fix (also includes the patch to fix bug 26685)

Comment 14

[John Bandhauer]

See the fix attached above. It looked to me like the real problem was that by 
creating the first window of the app (the splash screen) on another thread we 
were making Windows think that our main thread was a secondary UI thread and it 
was forcing our first browser window behind other apps' main windows. (see the 
comment in the patch). Note that using -quiet (to avoid the spash screen 
creation) avoided the z-order poblem.

This fix briefly shows a tiny offscreen window from the main thread before the 
spash screen. It worksforme. I tested on release and debug builds on NT4 and a 
debug build on Win95.

This sort of guesswork hackery is problematic. It *may* do something funky on 
some machines somewhere. I suppose that's waht daily builds and pre-releases are 
for :) If anyone knows of a reason why this fix is bad then speak up!

Comment 15

[Bill Law]

Good work, John.  I like the idea of avoiding the problem versus trying to 
rectify it after the fact.  I'd like to test this code thoroughly, however (the 
problem doesn't seem to occur on Win98, BTW, so I wonder if the "fix" might 
cause strange behavior there).

I'll update this bug when I've verified it.

Comment 16

[Bill Law]

Attachment: Patch with fixes for this bug and also bug #26685 (and some others).

Comment 17

[Bill Law]

Attachment: Minor fix to widget code to properly pick up program icon

Comment 18

[Phil Peterson]

per PDT this bug becomes PDT- on 2/25

Comment 19

[Bill Law]

I've attached two patch files.

The first is my adaptation of John's previously posted patch that fixes this bug 
and 26685.  I modified his code somewhat:

a. Don't reload the bitmap; instead get it from the bitmap control (John's code 
was missing the corresponding DeleteObject, which is no longer necessary with my 
change).

b. I reuse the splash screen dialog instead of creating a separate "phantom" 
one.

c. I also tweaked the .rc file to fix two other bugs relating to adding program 
icons (using IDI_APPLICATION solves that) and eliminating the empty task bar 
button corresponding to the splash screen (adding the WS_EX_TOOLWINDOW style 
solves that).

The second patch is a minor fix to mozilla/widget/src/windows/nsWindow.cpp that 
permits it to properly load the IDI_APPLICATION program icon (it should use 
GetModuleHandle(NULL) instead of NULL as argument to LoadIcon).

I've tested this on Win98 and WinNT, both with and without the console window 
and everything appears to be in order.

Comment 20

[Bill Law]

Fix checked in yesterday.

Comment 21

[Grace Bush]

seamonkey is up front on build 2000-02-25-09

Comment 22

[John G. Myers]

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

Comment 23

[Grace Bush]

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