Closed Bug 347513 Opened 15 years ago Closed 15 years ago

When switching windows, current window stays in front of display (even when it loses focus, as expected)


(Core :: Widget: Win32, defect)

Windows 2000
Not set





(Reporter: sgautherie, Assigned: neil)




(Keywords: regression, verified1.8.1.1)


(1 file)

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060804 SeaMonkey/1.1a] (nightly) (W98SE)

Since a few days(/weeks), it sometimes happen that
when I switch to another window, (either a SeaMonkey one or not)
the current window will stay in the front of the display,
even if it looses focus. (and I can work in the underlying/focused window)

I'm not sure yet what triggers this;
I see it "most often" with the Error Console,
but I think it already happened with MailNews too.

I'll post if/when I get more details.
I'm not too sure, but it could be that this is triggered by doing "something" while SeaMonkey is loading !?
[Mozilla/5.0 (Windows; U; Win98; en-US; rv: Gecko/20060729 SeaMonkey/1.0.4] (release) (W98SE)

No bug.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060821 SeaMonkey/1.1a] (nightly) (W98SE)

Steps to reproduce:
0. All opened applications are minimized. [or one can be left displayed...]
1. I start SeaMonkey by double-clicking on a ('-browser -jsconsole'} shortcut on my desktop.
2. While the splash screen is displayed I [restore and] _minimize_ another application window, using its upper-right button.
3. The Error Console appears first.
4. The Browser appears second and take the focus.
r. But the Error Console (will) stay in foreground, until minimized.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3) Gecko/20060604 BonEcho/2.0a3] (nightly) (W98SE)

No bug:
either the regression happened later, or it's specific to SeaMonkey startup ?!
Ever confirmed: true
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3) Gecko/20060701 SeaMonkey/1.1a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060715 SeaMonkey/1.1a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060723 SeaMonkey/1.1a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060725 SeaMonkey/1.1a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060726 SeaMonkey/1.1a] (nightly) (W98SE)

Regressed between these two builds: 2006-07-26-03 - 2006-07-27-04.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060727 SeaMonkey/1.1a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060801 SeaMonkey/1.1a] (nightly) (W98SE)


By guessing from the bonsai log,
I see only one (and likely :-)) culprit ?!
2006-07-26 12:06 	mozilla/widget/src/windows/nsWindow.h 	MOZILLA_1_8_BRANCH  	2/0  	Additional fix for bug 259816: Browser steals focus from program selected in 'Open With' dialog
Assignee: general → win32
Component: General → Widget: Win32
Product: Mozilla Application Suite → Core
QA Contact: general → ian
Summary: When switching window, current window stay in front of display (even while it looses focus, as expected) → When switching windows, current window stays in front of display (even when it loses focus, as expected)
Must be Win98 specific, I'll try to investigate. We can always make it just steal the focus on Win98 if necessary.
Assignee: win32 → emaijala
Today, I couldn't reproduce at first,
then I triggered bug 348723 (as a test), quit SeaMonkey, then I could reproduce.
A little later, after rebooting Windows, then even the BIOS, I could reproduce at once...
I suspect this is an Win98 specific oddity revolving around ForegroundLockTimeout (see I wasn't able to reproduce until I did the registry modification described at The weird thing is that the change is supposed to actually correct these issues but others have also reported odd behavior when ForegroundLockTimeout is zero. Serge, could you check what you have in the registry and if changing that helps? 
I checked [HKEY_CURRENT_USER\Control Panel\Desktop, ForegroundLockTimeout]:

Initially, this value did not exist;
I created one with a 0 (DWORD, Decimal), by using RegEdit.
I needed to restart Windows for it to take effect:

It seems to have cured both this bug and bug 348723 :-)
Target Milestone: --- → mozilla1.8.1
This bug is not Windows 98 specific. It also happens on Windows 2000, if the '-browser' switch is used.

Steps to reproduce:
1. Create a shortcut with 'seamonkey.exe -browser' in your start menu.
2. Start SeaMonkey by clicking that shortcut.
3. Click it again. A second SeaMonkey window opens. (Or, alternatively, open the preferences dialog or start some other application.)
4. Switch between those windows.

The (last) navigator window opened with '-browser' always stays on top of other windows, regardless of having focus or not. Even if you open other applications later on, the SeaMonkey window will obscure them.
If you minimize the SeaMonkey window and then maximize it again, the problem is gone.

Changing [HKEY_CURRENT_USER\Control Panel\Desktop, ForegroundLockTimeout] to 0 does not help on Windows 2000.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b2) Gecko/20060821 SeaMonkey/1.1a
> 3. Click it again. A second SeaMonkey window opens. (Or, alternatively, open
> the preferences dialog or start some other application.)

[...] alternatively, open the preferences dialog or start some other application *after* having opened at least *two* SeaMonkey windows.
Ah, if this is to do with windows being topmost (WS_EX_TOPMOST) then I've seen this randomly with my trunk build too, but no idea as to steps to reproduce.
Every time I launch trunk SeaMonkey with an always-on-top application focused (e.g. WinAmp, or my TV Tuner app), SeaMonkey makes itself always-on-top.  100% reproducible, and extremely annoying.  If this is on branch, it needs to be fixed.  Backing out the latest patch on bug 259816 fixed the bug for me.
Flags: blocking1.8.1.1?
In that case, I suspect the code that tries to show the window on top, but behind the foreground window - if the foreground window is topmost then it makes the new window topmost too.
Attached patch Possible patchSplinter Review
CTho, seeing as you seem to be able to reproduce the bug consistently, can you try this patch out to see if it works?
Attachment #242615 - Flags: review?(cst)
Comment on attachment 242615 [details] [diff] [review]
Possible patch

I'm not qualified to review this code.  However, the patch does fix the bug.
Attachment #242615 - Flags: review?(cst) → review?(emaijala)
Comment on attachment 242615 [details] [diff] [review]
Possible patch

Good. I never even thought that a window would become topmost if placed behind a topmost window.
Attachment #242615 - Flags: review?(emaijala) → review+
Comment on attachment 242615 [details] [diff] [review]
Possible patch

After rereading the somewhat confusing documentation I twigged the patch is correct and was immediately able to reproduce the bug but you need two topmost windows; when one is in the foreground and the existing code tries to put a window behind it that still places it in front of the other topmost window and therefore forces it to be topmost too.
Attachment #242615 - Flags: superreview?(roc)
Attachment #242615 - Flags: superreview?(roc) → superreview+
Fix checked in.
Closed: 15 years ago
Resolution: --- → FIXED
Comment on attachment 242615 [details] [diff] [review]
Possible patch

Fix for 1.8.1 regression.
Attachment #242615 - Flags: approval1.8.1?
On advice of #developers, also requesting blocking for this 1.8.1 regression.
Flags: blocking1.8.1?
Not a common enough happenstance for us to block Firefox 2, but as soon as the tree opens up we'll let this land if Seamonkey wants to get it in sooner, and we'll get it in for ...
Flags: blocking1.8.1? → blocking1.8.1-
Comment on attachment 242615 [details] [diff] [review]
Possible patch

Fair enough.
Attachment #242615 - Flags: approval1.8.1.1?
Yes, definitely a blocker for SeaMonkey release as far as I am concerned
Attachment #242615 - Flags: approval1.8.1?
Flags: blocking1.8.1.1? → blocking1.8.1.1+
Assignee: emaijala → neil
Comment on attachment 242615 [details] [diff] [review]
Possible patch

approved for 1.8 branch, a=dveditz for drivers
Attachment #242615 - Flags: approval1.8.1.1? → approval1.8.1.1+
Fixed checked into MOZILLA_1_8_BRANCH
Keywords: fixed1.8.1.1
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20061120 SeaMonkey/1.1b] (nightly) (W98SE)

V.Fixed on MOZILLA_1_8_BRANCH, between these two builds.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20061121 SeaMonkey/1.1b] (nightly) (W98SE) [2006-11-21-13]

Thanks Neil !
OS: Windows 98 → Windows 2000
Version: 1.8 Branch → Trunk
You need to log in before you can comment on or make changes to this bug.